ISC2 Certified Cloud Security Professional (CCSP) Practice Test

ISO/IEC 20000-1 (and ITIL) call for a controlled repository that records the relationships between service assets and their configuration items. A configuration management database (CMDB) that is continuously updated by the orchestration workflow becomes the single source of truth, allowing operators and auditors to query the current or historical state of any cloud resource and to trace changes. Auto-scaling policies, blue/green deployments, and object versioning provide useful operational capabilities, but none of them on their own maintains the complete, queryable inventory and relationship data that formal configuration management demands.

Abuse case testing focuses on how a malicious or careless actor could intentionally misuse the application and the cloud environment. Flooding the public API with scripted calls that exceed the documented rate limits tries to force the application to over-consume backend capacity, potentially starving other tenants. Observing whether the service throttles, generates alerts, and logs the behavior validates protections against this abuse scenario. Unit tests of valid inputs, static code analysis for coding flaws, and reviewing acceptance criteria all contribute to quality or secure development, but they target normal usage or code issues rather than intentional misuse aimed at resource exhaustion.

Service level management focuses on defining, negotiating, monitoring, and reporting the level of IT services delivered. For an availability commitment to be meaningful, the SLA must specify exactly how availability is measured-its calculation formula, the length of the measurement period (for example, a calendar month), the clock that is used, what events count as downtime, and any planned-maintenance exclusions. Without that definition, neither party can objectively verify whether 99.95 % was achieved or determine if service credits are due. While security certifications, data-location clauses, and penetration-testing schedules are important, they relate to compliance and security management rather than the core availability metric that service level management tracks and reports.

Lightweight hypervisor-based runtimes such as Kata Containers launch each pod inside its own micro-VM. Because the guest kernel is separated from the host kernel by hardware virtualization boundaries, a compromise inside the container does not give the attacker direct access to the host or to containers in other namespaces.

PodSecurityPolicies and AppArmor profiles can remove Linux capabilities and restrict system calls, but the workload still shares the host kernel, so a kernel-level escape remains possible. Kubernetes network policies control East-West traffic but provide no protection against host breakout. Therefore, using a hypervisor-isolated container runtime offers the strongest containment with minimal application changes.

Static data masking that applies format-preserving substitution overwrites every sensitive value with a fictitious value that retains the original data type, length, and pattern-for example, replacing a 16-digit credit-card PAN with another valid-looking 16-digit number. The masking engine may use an internal secret or seed to generate the replacement values, but because it keeps no lookup table and the key or seed can be destroyed after masking, the cloud copy cannot be reverted to the original data, satisfying the requirement for irreversibility while still giving developers realistic test data.

Format-preserving encryption, on the other hand, is designed to be decrypted whenever the key is available, and vault-based tokenization always allows detokenization via the vault, so both violate the "never expose" mandate. Simply replacing the columns with NULL removes the realistic patterns that functional tests rely on, making it unsuitable for development use.

In the IaaS shared-responsibility model, the cloud provider protects the physical datacenter, network, and virtualization layer, including the hypervisor and managed storage services. However, the tenant is accountable for the security of the guest operating system, applications, and data within each instance. Failing to patch or harden the OS leaves software vulnerabilities that attackers can exploit for remote code execution-this risk lies squarely with the customer. Risks such as hypervisor side-channel attacks, failures of the provider's encryption service, or provider-level DDoS events are primarily mitigated by the cloud service provider under its contractual obligations and infrastructure controls, though customers may implement additional safeguards.

Because the cloud stores only random, format-preserving tokens that contain no exploitable PAN information, the cloud portion of the solution no longer handles cardholder data directly, significantly reducing its PCI DSS scope. However, PCI DSS still requires an assessment of any system- including the cloud environment-if it could influence the security of the on-premises cardholder data environment (CDE). The incorrect options either assume scope is eliminated entirely, misunderstand tokenization as hashing, or suggest moving the vault (which would keep the cloud fully in scope).

Encrypting data on the client side with keys that remain under the customer's exclusive control ensures that ciphertext, not plaintext, is delivered to the cloud service. Because the keys are generated and held in an on-premises Hardware Security Module (HSM) that integrates with a cloud key-management service through secure APIs, the cloud provider never gains access to either the plaintext data or the encryption keys, fulfilling the requirement to prevent provider personnel from reading the PII. Server-side or volume-level encryption with provider-managed keys still exposes the keys to the provider's control, and relying solely on TLS secures data in transit but leaves it unprotected at rest. Therefore, client-side encryption with customer-managed keys is the most appropriate choice with minimal additional operational burden beyond key management that the organization already performs on-premises.

Factor Analysis of Information Risk (FAIR) was created specifically to quantify information and technology risk in financial terms, providing estimates of probable loss magnitude and frequency. This aligns exactly with management's request for a money-based view of cloud threats.

OCTAVE offers a structured, primarily qualitative approach that focuses on organizational self-assessment rather than detailed financial modeling. ISO/IEC 31000 provides broad principles and a high-level process for risk management but leaves quantification methods to practitioners. The COSO Internal Control - Integrated Framework concentrates on internal control effectiveness and financial reporting assurance, not on calculating expected loss from specific IT threats. Therefore, FAIR is the only framework designed to translate information-risk scenarios into monetary values, making it the most suitable choice.

The spiral model structures development as a series of iterations (or "spirals"). Each loop begins with objectives and alternatives, followed by a dedicated risk analysis phase. The results of that analysis drive prototyping, design, coding, and testing for that iteration, so high-risk items are addressed early and continuously. Waterfall and the V-model are linear, locking requirements up front and delaying risk discovery. Agile/Scrum is iterative, but it does not mandate formal risk analysis at the start of each cycle. Therefore, the risk-driven spiral model is the most suitable choice.

A SOC 1 Type II report describes the controls operated and tested at the service-provider level. Physical security of the datacenter, patch management of the virtualization hosts, and configuration of the perimeter firewalls are all provider-managed controls that have already been independently assessed in the CSP's report. Provisioning and de-provisioning user accounts inside the ERP application, however, is a logical access control exercised by the customer's own administrators. Because that activity directly affects the integrity of the customer's financial records and is not performed by the provider, it must be tested by the customer's internal auditors to satisfy SOX requirements. The other options are provider-side controls that can be relied upon through the external SOC report and therefore do not normally require additional internal testing.

Applying seccomp and AppArmor (or SELinux) profiles to each container enforces a whitelist of allowed Linux system calls and capabilities. If an attacker escapes the application but remains inside the container, attempts to invoke disallowed kernel functions-such as loading kernel modules, changing network settings, or escalating privileges-will be blocked, reducing potential impact. Moving worker nodes to a private subnet improves network exposure but does not constrain kernel interactions. Disallowing the :latest tag helps with image provenance yet offers no runtime syscall restriction. Mounting the Docker socket greatly increases risk because it grants containers control over the host daemon, the opposite of the desired effect.

Tokenization replaces a sensitive value with a surrogate that is not derived through a mathematical algorithm, so it cannot be reversed without access to the token vault or mapping service. Because the organization defines the token format, it can mirror the original data's length, character set, and even preserve portions (for example, the first six and last four digits of a PAN). This lets existing applications and cloud data-warehouse functions-such as joins, sorting, or grouping by the preserved digits-operate without exposing the real PAN. Standard encryption, even when format-preserving, produces ciphertext that is still mathematically related to the plaintext and must be decrypted (or use more complex searchable encryption) before meaningful analytics can occur. Tokenization does not inherently provide compression, does not rely on homomorphic encryption, and still requires secure storage of token mappings; tokens themselves do not embed cryptographic key material.

Threat modeling provides the most value when it is performed once the system architecture has taken shape but before implementation begins, allowing security requirements and design changes to be incorporated with minimal cost. In a classic SDLC, this aligns with the design (or architecture) phase, which follows requirements analysis and precedes coding. Performing threat modeling later, during implementation or testing, uncovers issues after code has been written, leading to greater re-work, while performing it during initial requirements gathering is premature because architectural details needed to model threats are not yet available.

A service level agreement (SLA) is the portion of the cloud services contract that spells out measurable service commitments, including availability targets, support response times, and security-incident notification and escalation requirements. By embedding time-bound communication and remediation obligations in the SLA, the cloud customer gains a contractual basis for enforcing prompt vendor response. A statement of work focuses on project deliverables rather than ongoing operational duties, a business impact analysis is an internal risk assessment tool, and a data processing addendum governs privacy and data protection terms-not real-time incident reporting expectations.

A pilot light strategy keeps a minimal copy of the production environment (core databases and critical services) continuously replicated in a secondary region. Because only essential components are running, operating costs stay low. When a disaster occurs, additional application servers can be started from pre-created images and the data store is promoted, allowing service restoration in tens of minutes-well within the 2-hour RTO-and with data loss limited to the replication window of a few minutes, meeting the 15-minute RPO. Backup-and-restore usually exceeds both the RTO and RPO because large volumes must be restored. Warm standby keeps a scaled-down but fully functional environment continuously running, offering faster recovery but at higher ongoing cost than necessary. An active-active multi-site setup delivers near-zero RTO/RPO but is the most expensive option and was explicitly ruled out.

A Trusted Platform Module (TPM) provides a hardware root of trust that can securely store cryptographic measurements of the BIOS, bootloader, and hypervisor during the boot process. Using secure or measured (trusted) boot, the TPM can sign these measurements so that a remote attestation service-such as OpenStack's Trusted Compute or cloud-provider-specific attestation services-can verify that the host has not been tampered with before allowing it to join the resource pool.

A Hardware Security Module (HSM) mainly protects cryptographic keys for applications and does not measure or attest to the integrity of the boot chain. Network Access Control (802.1X) governs port-level network admission and does nothing to ensure firmware or hypervisor integrity. Self-encrypting drives safeguard data at rest but cannot validate the overall platform's software stack at boot time. Therefore, deploying TPM-based secure/trusted boot is the correct control to meet the stated policy.

A fundamental requirement for detecting even the smallest modification to data is that the hash output change dramatically when any single bit of the input changes. This property is known as the avalanche effect. Without the avalanche effect, an attacker or an unintentional error might alter data while producing only a minor or predictable change in the hash, defeating integrity checks. Key stretching strengthens weak passwords against brute-force attacks but is unrelated to change detection. Confusion is a property of ciphers that hides relationships between plaintext, ciphertext and key, not hashes. Forward secrecy concerns session key derivation in encryption protocols and has no bearing on file integrity monitoring.

Forensic collection generally follows the order of volatility principle: data most likely to change or disappear is captured before less-volatile information. In a live virtual machine, RAM contains running processes, encryption keys, network connections, and other transient artifacts that can be lost as soon as the system is shut down or altered. A hypervisor-level memory snapshot captures this volatile data with minimal impact on the guest. Virtual disk snapshots, API logs, and archived firewall logs are all less volatile because they are written to persistent storage and can be retrieved later without significant risk of loss or alteration. Therefore, acquiring the memory dump first best preserves critical evidence while maintaining its integrity.

GDPR Article 33 requires that the controller notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The regulation only permits delays beyond this window when a reasoned justification can be documented. A 24-hour window is sometimes recommended by best-practice guidance but is not mandated. Seven days or an immediate one-hour deadline are not recognized by GDPR and would either create unnecessary operational burden or fall short of the legal requirement.