ISC2 Certified Cloud Security Professional (CCSP) Practice Test

Federating the cloud provider with the corporate identity store using SAML 2.0 allows users to present their existing Active Directory credentials through single sign-on. Group claims in the SAML assertion can be mapped to narrowly scoped IAM roles so that only members of the HR support group receive the administration privileges needed for the workload, satisfying the principle of least privilege. Creating local cloud accounts would duplicate identities and require additional password management. Anonymous access removes all authentication, conflicting with policy. Embedding shared root-level SSH keys provides no fine-grained authorization and violates least-privilege requirements.

Zero-trust networking assumes no implicit trust based on location inside the VPC. Microsegmentation tools embed a software-defined firewall on or very close to every workload and build policies tied to verified identity, tags, and context (such as device health or time of day). Because rules follow the workload and are evaluated for every east-west flow, this approach enforces the zero-trust principle of continuous, identity-centric verification. Perimeter firewalls and VLAN moves rely on coarse network boundaries, while widening CIDR blocks further weakens isolation.

NIST Special Publication 800-145 lists five essential characteristics of cloud computing. "On-demand self-service" means a consumer can unilaterally provision computing capabilities, such as server time and network storage, automatically without requiring human interaction with each service's provider. This matches the requirement that developers provision and de-provision resources whenever needed via a portal or API. Resource pooling refers to the provider's shared resource model, broad network access concerns ubiquitous connectivity, and measured service is about metering resource use. None of those characteristics alone guarantee users can obtain resources without provider involvement, so they are incorrect.

Measured service is one of the NIST-defined essential characteristics of cloud computing. It refers to the cloud provider's ability to automatically control and optimize resource use by leveraging metering capabilities that monitor, report, and bill on a per-usage basis. Because consumption is precisely measured, an organization can implement chargeback or show-back processes tied to actual resource utilization. Rapid elasticity deals with automatic scaling, broad network access addresses ubiquitous connectivity, and multi-tenancy describes logically isolated sharing of pooled resources; none of these characteristics alone provide the detailed metering required for cost allocation.

Because the data reside in a relational (structured) database, the quickest and most accurate way to discover PII is to query the database's system catalog to obtain table and column definitions, data types, and any existing sensitivity or classification tags. Leveraging this metadata lets a discovery tool focus directly on columns likely to contain PII (for example, CHAR(9) columns named SSN or customer_ssn), reducing the need for pattern matching across every row and thus minimizing false positives.

Scanning exported flat files with regular expressions can locate patterns but typically produces many false positives and misses context such as column semantics. Network DLP only observes data in motion; it does not enumerate where data are stored inside the database. Applying homomorphic encryption is a protection technique, not a discovery method, and would actually make content inspection impossible unless decrypted first. Therefore, using the database catalog and schema metadata is the most appropriate discovery technique for structured data.

Container orchestration frameworks such as Kubernetes and Amazon Elastic Kubernetes Service include native auto-scaling features (for example, the Horizontal Pod Autoscaler) that monitor metrics like CPU usage or custom application signals and automatically start or terminate additional container replicas to match demand. This on-demand horizontal scaling delivers the rapid elasticity promised by cloud computing. While sharing a host kernel, overlay networking, and secret management are valuable functions, none of them directly provide the capability to grow and shrink the number of running service instances in response to load.

NIST Special Publication 800-145 lists rapid elasticity as one of the five essential cloud characteristics. Rapid elasticity means resources can be provisioned and released quickly-often automatically-to scale out or in commensurate with demand, and to appear to customers as unlimited. On-demand self-service allows unilateral provisioning but does not inherently include automatic scaling. Resource pooling is about multi-tenant sharing of provider resources, and measured service refers to metering and billing, not dynamic capacity expansion.

To ensure that technical controls activate reliably in each cloud, the same label must appear on every object no matter where it is stored. Defining one authoritative classification taxonomy and requiring all teams to use an identical tag key-value syntax across AWS, Azure, and GCP eliminates the need for per-provider translations and removes the risk that data will lose its meaning when copied or migrated. Relying on provider-specific labels or letting users invent their own introduces inconsistency; focusing only on PII overlooks other sensitive data classes and does not address the enforcement consistency problem.

The scenario involves an attacker in one tenant environment leveraging a hypervisor or other shared infrastructure weakness to break the logical separation that normally isolates customers in a multi-tenant cloud. This is commonly classified as an exploitation of shared technology vulnerabilities or isolation failure. Phishing targets user credentials rather than hypervisor flaws; data remanence deals with residual data on retired media; vendor lock-in is a business risk, not a technical cross-tenant threat.

During live migration, the entire contents of a VM's memory and CPU state are streamed across the management network. If that traffic is sent in clear text on an unsegmented network, a malicious insider or attacker with access to the network can capture sensitive data such as encryption keys or personally identifiable information resident in RAM. Performance impact, software licensing, and guest OS patching are operational considerations, but they do not directly threaten the confidentiality of data in transit during migration, making data exposure the primary risk in this scenario.

The scenario describes the customer provisioning, altering, and de-provisioning resources unilaterally through a self-service interface. NIST identifies this as on-demand self-service. Rapid elasticity refers to the automatic scaling of capacity, resource pooling concerns abstracting and sharing provider resources among multiple customers, and measured service relates to metering and chargeback-all important but none guarantee user-initiated provisioning without provider interaction.

The described scenario matches the NIST essential characteristic called "resource pooling." Resource pooling refers to the provider's use of a multi-tenant model to serve multiple customers with dynamically assigned physical and virtual resources, with location independence so customers cannot tell (and often do not control) the exact hardware in use. Rapid elasticity focuses on quick scaling, broad network access emphasizes ubiquitous connectivity, and on-demand self-service involves customers provisioning resources without human interaction. None of those specifically require resources to be abstracted from their physical location and shared among tenants; that capability is unique to resource pooling.

A SaaS provider owns responsibility for the entire application stack, including the guest operating system. Good hygiene requires that patches be incorporated into the standard build so every new or rebuilt instance starts from a known-good state. The recommended first step is therefore to update the hardened golden image, verify it in a staging environment, and then redeploy or rebuild production instances from that patched baseline. Patching live production systems without testing risks stability issues, simply notifying customers shifts responsibility incorrectly, and relying on network blocks leaves the vulnerability un-remediated.

Chain of custody demands a verifiable record that the evidence has not been altered from the moment it is collected. Calculating a cryptographic hash (such as SHA-256) at the time of collection establishes an integrity reference. Storing that hash inside a time-stamped manifest that is itself digitally signed-with the collector's X.509 private key-creates an auditable record tying the evidence to a specific, authenticated identity. The digital signature delivers non-repudiation because the signer cannot later deny performing the action, and any change to the manifest or the log alters the signature validation. Simply encrypting data, enabling WORM storage, or writing to a blockchain may help with confidentiality or tamper evidence, but without a collector-bound digital signature and an original hash, they do not fully satisfy both integrity across the chain of custody and non-repudiation.

API-based integration with the cloud application (often delivered by a CASB or cloud-resident DLP engine) authenticates to the SaaS provider and scans the tenant's existing content at rest. Because inspection occurs directly via the provider's APIs, no network redirection or host agent is needed.

• A secure web gateway or ICAP proxy can only see data in motion that passes through the proxy; it cannot reach content already stored in the cloud.
• Endpoint DLP agents inspect data in use or in motion on the host but do not have native access to files that were uploaded earlier from another device.
• An SMTP DLP gateway inspects email traffic only and offers no visibility into files stored in collaboration platforms. Therefore, API-based DLP is the only option that satisfies continuous inspection of at-rest SaaS data without altering network paths or endpoints.

Ephemeral (instance-attached) storage is provisioned on physical disks that are directly attached to the hypervisor host. Cloud providers automatically wipe this storage when the associated virtual machine is stopped, terminated, or migrated, eliminating residual-data concerns and avoiding charges once the instance is gone-making it ideal for short-lived, non-persistent data such as session caches.

Long-term object storage classes are designed for durable retention and charge for both capacity and retrieval; using them for transient cache files would increase cost and leave data remnants unless explicitly deleted. Raw block storage mapped directly to physical devices is intended for workloads that need persistent low-level disk access (for example, databases) and normally remains allocated until manually detached, so cached data could persist inadvertently. A network file share on durable distributed storage is likewise persistent, incurs additional latency, and would retain the session data beyond the VM's life. Therefore, ephemeral storage best satisfies the requirements of low cost and automatic data destruction.

Disabling all forms of PCI, USB, or other device passthrough removes the vulnerable code path that the newly disclosed flaw exploits, forcing each guest to use only emulated or paravirtualized devices that remain under the hypervisor's complete control. This action immediately reduces the probability of guest-to-host escape without waiting for patch deployment. Network segmentation, key placement, and memory deduplication do not address the hypervisor interface that the exploit targets, so they provide little or no protection against the initial breakout.

Validating open-source software goes beyond simply trusting the origin or isolating the runtime. The security team needs verifiable evidence that the exact bits being deployed are known, scanned, and tracked. Generating a software bill of materials (SBOM) with a Software Composition Analysis (SCA) tool exposes all third-party components inside the image and maps them to known CVEs, enabling remediation or documented risk acceptance. Pulling from an "official" repository or forking the code without scanning provides no assurance about hidden vulnerabilities. Relying only on runtime monitoring detects issues after deployment, not before, and does not meet the definition of pre-deployment validation.

Tokenization replaces the sensitive value with a surrogate (token) and stores the original value in a separate, secure token vault that the cloud provider cannot access. Because the same input will always return the same token (deterministic tokenization), the SaaS application can perform equality searches on the tokenized SSN while the real SSN remains hidden. When necessary, the organization can reverse the process by querying the vault to retrieve the original value.

Hashing with a salt is intentionally one-way, so the original SSN cannot be recovered, violating the legal discovery requirement. Static data masking permanently alters or removes sensitive characters, likewise preventing restoration. Format-preserving encryption is reversible, but without giving the provider access to the encryption key the application could not perform direct equality searches on ciphertext, and exposing the key to the SaaS operator would violate the requirement that the provider never see the real data. Therefore, tokenization with an on-premises mapping vault is the most appropriate choice.

ISO/IEC 17788 and ISO/IEC 17789 categorize provider tasks that change the parameters of an already-provisioned cloud-service instance-such as creating or deleting user accounts, assigning roles, modifying quotas, or adjusting policy settings-under the Configure activity. Cloud service usage is carried out by the customer when actually using the application, support involves helping the customer resolve incidents or answer questions, and provisioning refers to the automated creation of the initial service instance. Therefore, the operator's actions constitute the Configure activity.