CCSP sample questions — 25 answered and explained

ISO/IEC 17788 defines multi-tenancy as allocating resources so that tenants, their computations and their data are isolated from and inaccessible to one another.

The defining idea is isolation between tenants that share resources. Resource pooling is the close distractor because sharing is involved in both, but pooling describes dynamic assignment by demand. A shared schema with a tenant ID column is one way to build multi-tenancy, not its definition, and multi-cloud is about one customer using several providers.

1. Recall that ISO/IEC 17788 lists multi-tenancy as a key characteristic.
2. Find the word that defines it: isolation between tenants.
3. Separate it from pooling (assignment by demand) and from implementation patterns.

Exam tip: Pooling is about sharing. Multi-tenancy is about keeping the sharers isolated from each other.

Broad network access makes services reachable from many devices and places, so endpoint and identity controls matter more.

Being reachable from any device over standard protocols is broad network access. Its direct security cost is a larger attack surface: unmanaged devices and remote attackers can reach the same login pages. Each distractor is a real cloud risk, but each comes from a different characteristic: pooling (location), multi-tenancy (isolation) or self-service (governance).

1. Name the characteristic described: broad network access.
2. Ask what wider reachability changes for an attacker.
3. Trace each distractor to the characteristic it actually comes from.

Exam tip: Reachable from anywhere means attackable from anywhere: broad network access puts identity and endpoint controls first.

The NIST definition ends with resources that are rapidly provisioned and released 'with minimal management effort or service provider interaction'.

The defining phrase is about minimal management effort and minimal interaction with the provider. That is what links the definition to self-service and automation. Contracts, dedicated hardware and SLAs are real parts of how cloud is bought, but none is part of the definition.

1. Recall the end of the NIST definition.
2. Check each option against the 'shared pool' already in the stem; dedicated hardware conflicts with it.
3. Separate commercial terms (contracts, SLAs) from the definition itself.

Exam tip: Cloud is shared, configurable resources provisioned and released quickly with minimal effort or provider interaction.

The cloud service customer, as data owner, keeps ultimate accountability for its data even when a provider handles it.

The core rule is that responsibility can be shared or delegated but accountability stays with the data owner, here the clinic. The provider is the tempting answer because the flaw was its own. It may well be liable under contract or as a processor, but that does not remove the clinic's accountability to its patients and regulators.

1. Identify who owns the data: the clinic.
2. Separate accountability, which stays with the owner, from responsibility, which can be shared.
3. Treat provider fault as a contract and liability matter, not a transfer of accountability.

Exam tip: You can outsource the work but not the accountability: the customer answers for its data.

In ISO/IEC 17789 the cloud auditor is a sub-role of the cloud service partner, alongside the cloud service developer and cloud service broker.

ISO/IEC 17789 has three main roles: cloud service customer, cloud service provider and cloud service partner. The auditor is a sub-role of the partner. The provider's own security and risk sub-role is the near-twin, but an independent assessor sits outside the provider. A regulator sets rules rather than giving an opinion.

1. Recall the three ISO/IEC 17789 roles.
2. Place the independent assessor outside both the customer and the provider.
3. Recall that the auditor is a partner sub-role, distinct from a regulator.

Exam tip: The auditor is a cloud service partner sub-role. It examines and reports, it does not set rules.

Archive is long-term retention after active use; its distinctive concern is that the data stays retrievable and readable.

Records moved to cold or archive storage may sit untouched for years. The risks specific to this phase are that the file format can no longer be opened, the software to read it is gone, or the encryption keys were retired. Each of the other options is a sound control, but each belongs to a different phase: rights management to Share, query monitoring to Use and labelling to Create.

1. Identify the phase: long-term retention after active use is Archive.
2. Ask what can go wrong with untouched data over years: it becomes unreadable.
3. Match each other control to its own phase.

Exam tip: Archiving is only as good as your ability to read the data later: keep formats, software and keys.

The data lifecycle is a model, not a mandatory path: data can skip phases and move back from Archive to Use.

Different data types follow different paths. Logs may never be shared or archived, and archived records can be brought back into active use. A control matrix should therefore follow the phases each data type really passes through, including returns to earlier phases. Marking skipped phases as not applicable keeps the false single forward path, and treating a restore as Create or as a new Store event mislabels what is a return to Use.

1. Notice the matrix assumes one fixed path.
2. Compare it with the two real paths described.
3. Recall that phases can be skipped and revisited.
4. Choose the change that maps controls to actual paths.

Exam tip: Map controls to the path data actually takes: phases can be skipped and revisited.

The data lifecycle is repeated in every location data reaches, and the movements between locations carry their own risks.

The CSA model adds locations to the lifecycle: data is created in one place, copied or moved elsewhere and used again, and each environment has its own owner, service model and controls. The laptops are company endpoints and the warehouse runs on IaaS, where the customer carries much more responsibility than in SaaS. Mapping only the system of record leaves the export and load flows and both destinations uncovered. Endpoint DLP, classification labels and copied roles each fix a slice of the problem; only mapping every location and transition addresses it.

1. List every place the data lands: CRM, laptops, warehouse.
2. Recall that each location runs its own lifecycle with its own controls.
3. Include the transfers between locations.
4. Reject options that cover only one location or rely on another party's control.

Exam tip: Data's lifecycle restarts wherever it lands: map each location and every move between them.

The CSA lifecycle model pairs phases with three functions, Access, Process and Store, performed by actors in locations.

For each phase and location, the model asks who (actor) can do what (function) to the data, and which controls allow or restrict it. The functions are Access, Process and Store. The phase names are the tempting distractor because they sound like actions, but they describe where data is in its life, not what an actor does to it.

1. Separate phases (where data is in its life) from functions (what actors do).
2. Recall the three functions: Access, Process, Store.
3. Reject permission sets and privacy terms that use different vocabularies.

Exam tip: Phases say where data is in its life; functions (Access, Process, Store) say what an actor does to it.

Data dispersion (bit splitting) protects confidentiality by ensuring no single storage location holds enough to rebuild the data.

Splitting data into encrypted fragments across providers means an attacker or insider at one provider sees only meaningless pieces. That is the main security benefit. It does not let a single provider vouch for whole files, it adds processing and latency rather than removing it, and it leaves the company's residency and key-management duties in place.

1. Note the design rule: no provider holds enough to rebuild.
2. Ask what a compromise of one provider yields: fragments only.
3. Reject claims of per-provider integrity checks or speed gains.

Exam tip: Dispersion's main gain: compromise one location and you get fragments, not data.

Overlay isolation is logical separation, not confidentiality.

VXLAN keeps tenants apart by tagging their encapsulated frames, so the switches deliver each frame only to the right segment. But the encapsulation adds no encryption or authentication: an insider or tap on the physical network reads the inner traffic directly. Going back to VLANs does not help either, because a VLAN tag is just as readable. Separation answers the isolation requirement; confidentiality on shared links needs encryption in transit, such as IPsec between hosts or TLS in the workloads.

1. Distinguish isolation (who receives traffic) from confidentiality (who can read it).
2. Recall that VXLAN adds a header and identifier but no encryption.
3. Recommend encryption in transit where confidentiality on shared links is required.

Exam tip: An overlay keeps tenants apart; only encryption keeps their traffic unreadable on the wire.

Infrastructure traffic types are separated onto isolated networks.

Each traffic type has a different trust level and risk. Management traffic controls the hosts, migration traffic carries VM memory, storage traffic carries disk data, and tenant traffic is the least trusted. Keeping each on its own isolated network, physical or logical, limits what a compromised workload can reach and prevents a busy flow from degrading the rest. The other designs each leave two sensitive types sharing a network.

1. List the traffic types and their sensitivity.
2. Ask which pairs could harm each other if they shared a network.
3. Choose the design that isolates every type.

Exam tip: Management, migration, storage and tenant traffic each get their own isolated network.

Traffic between VMs on one host stays inside the virtual switch.

A hypervisor's virtual switch connects the virtual NICs of its guests. When both endpoints are on the same host and network, frames are delivered in memory and never cross a physical cable. That matters for security because sensors and firewalls on the physical network cannot see that traffic, so inspection must be done in the virtual layer.

1. Note that both VMs share a host and a virtual network.
2. Recall how a virtual switch delivers local frames.
3. Conclude that the traffic never reaches the physical network.

Exam tip: Same host, same virtual network: the traffic never touches a physical wire.

Physical network sensors are blind to east-west traffic inside one host.

Two facts explain the silence. The two VMs share a host, and their traffic is switched in the hypervisor's virtual switch, so it never reaches the inter-rack links where the sensors sit. Therefore any fix located on the physical network, such as better signatures, inline placement or edge decryption, still sees nothing. The fix is to inspect at the virtual layer, with a virtual IDS, a distributed firewall that follows each VM, or hypervisor-level traffic mirroring.

1. Notice the detail: both VMs were on the same host.
2. Recall where network sensors normally sit: on physical links fed by switch ports.
3. Ask whether same-host traffic ever crosses those links.
4. Choose a fix that moves inspection into the virtual layer.

Exam tip: If two VMs share a host, monitor where they meet: in the virtual switch, not on the physical network.

Mishandling of Exceptional Conditions (A10:2025) is new in the 2025 edition and covers errors and abnormal states that leave a system insecure.

The authorization logic works when the service answers; the flaw is that an exception path grants access. OWASP's new A10 category maps CWE-636, not failing securely, and its guidance is to fail closed. Broken Access Control is tempting because the outcome is unauthorised access, and the item turns on separating the outcome from the cause. Logging would only record the event after it happened.

1. Ask what triggers the flaw: an error condition, not normal authorization logic.
2. Recall that failing open is mapped to the new 2025 category for exceptional conditions.
3. Prefer the root-cause category over the one describing the impact.

Exam tip: An error path that grants access is failing open; teach developers to fail closed.

OWASP's API list splits authorization failures by level: object (API1), object property (API3) and function (API5).

The endpoint accepts an object identifier and returns that object without checking ownership. That is Broken Object Level Authorization, API1:2023 and the most common API flaw. BFLA would mean calling an operation the role should not reach, and BOPLA would mean seeing or changing individual fields of an object the caller may otherwise access.

1. Note that the caller supplies an object identifier.
2. Spot the missing check: does this object belong to the caller?
3. Map a per-object check failure to BOLA.

Exam tip: Changing an ID in an API call to reach someone else's object = BOLA (API1).

Function level authorization decides which operations each role may call; object level authorization decides which records a caller may touch.

The ordinary user's token reaches an operation meant only for administrators, so the role check on the function is missing. That is Broken Function Level Authorization. BOLA is the near-twin and applies when a caller reaches another user's object through a function they are allowed to use. Inventory management would apply if the endpoint were forgotten or undocumented.

1. Ask whether the user should be able to call this operation at all.
2. Note that the operation belongs to an administrative role.
3. Map a missing role check on an operation to BFLA.

Exam tip: Wrong role reaching an operation = BFLA; wrong user reaching an object = BOLA.

API3:2023 Broken Object Property Level Authorization merged the older excessive data exposure and mass assignment risks.

The tester may edit this object through this operation, so object and function level checks both pass. What fails is authorization at the property level: the endpoint binds a field the user should not control. OWASP's 2023 list groups mass assignment and excessive data exposure as Broken Object Property Level Authorization. The fix is to allowlist the properties each caller may read or write.

1. Confirm the object belongs to the caller, which rules out BOLA.
2. Confirm the operation is one the caller may use, which rules out BFLA.
3. Locate the flaw at the level of an individual field.
4. Recall that mass assignment now sits under BOPLA.

Exam tip: Right object, right operation, wrong field = BOPLA (mass assignment).

A trusted platform module (TPM) is a per-platform hardware root of trust that stores measurements, keys and attestation identities.

Platform configuration registers cannot be written directly, only extended with a new hash, so their final value summarises the whole boot chain. The TPM signs those values for a remote verifier. Secure boot is related but different: it enforces signatures at load time rather than recording what loaded. An HSM and a BMC have other jobs.

1. Note the two features asked for: extend-only registers and remote verification.
2. Recall which chip holds platform configuration registers.
3. Separate recording a boot (measured boot) from enforcing signatures (secure boot).

Exam tip: TPM PCRs record how a machine booted; secure boot decides what may boot.

TPM sealing binds a secret to specific PCR values, so it can be unsealed only on a platform in that measured state.

The requirement couples key release to the integrity of the boot chain. Sealing to PCRs does exactly that. Secure boot is a near-twin: it stops unsigned components, but a signed yet unapproved version, or a tampered configuration, can still boot and the key would be released anyway. A password or a device identity says nothing about what booted.

1. Identify the condition for release: an unchanged boot chain.
2. Ask which mechanism checks the measured state at release time.
3. Separate signature enforcement and identity from state-bound key release.

Exam tip: Want a key only on an unaltered platform? Seal it to the TPM's PCRs.

Sealed secrets are tied to exact PCR values, so any legitimate change to measured components requires resealing.

Two facts combine here. The firmware is measured into the PCRs, so an update changes their values, and a sealed key unseals only when the current values match. A legitimate update therefore needs a planned reseal to the new expected values (or a temporary protector during the change). Binding keys to the endorsement key abandons the measured-boot check and misuses an identity key, secure boot is not the mechanism blocking the unseal, and the endorsement key is a permanent identity unrelated to firmware.

1. Recall that firmware is part of the measured boot chain.
2. Recall that sealing requires the current PCR values to match.
3. Conclude that an approved change must include resealing.
4. Reject actions that drop the integrity check or touch unrelated mechanisms.

Exam tip: Change a measured component and you must reseal, or the platform locks itself out.

A virtual TPM (vTPM) emulates a TPM for one VM; its state is stored with the VM and must itself be protected.

Guest OS features that need a TPM look for a TPM device inside the VM. The hypervisor supplies that as a vTPM per VM. Because the vTPM's secrets sit in the VM's files rather than in a chip, platforms protect them by encrypting the VM state. The host's physical TPM belongs to the host, a network HSM is not a TPM device, and secure boot is a different feature.

1. Note that the guest OS itself needs a TPM device.
2. Recall that a physical TPM serves the host, not its guests.
3. Choose the per-VM virtual TPM and remember where its secrets are stored.

Exam tip: Guests get a vTPM each; protect it by encrypting the VM files where its secrets live.

Compelled disclosure reaches what the provider controls; keeping keys outside the provider limits that to ciphertext.

Two facts decide this. First, a provider can be compelled to disclose data it controls wherever it is stored, so residency and contract terms leave the data readable. Second, keys held in the provider's key management service, even if customer-managed, are usable by the provider's systems, so they are within its control too. Only client-side encryption with keys held by the insurer leaves the provider able to produce nothing but ciphertext, and that works here because the archives need no processing in the cloud.

1. Read the requirement: the provider must be technically unable to produce readable data.
2. Ask who can use the decryption keys under each option.
3. Pick the option where keys never enter the provider's control, noting no cloud processing is needed.

Exam tip: If the provider can use the key, it can be compelled to use it; hold your own keys when that matters.

GDPR Article 48 routes foreign court and authority demands for personal data through international agreements such as MLATs.

A direct order from a non-EU court conflicts with the processor's GDPR obligations. Article 48 resolves the conflict on the EU side: such a judgment or decision can be recognised or enforced only if it rests on an international agreement, typically a mutual legal assistance treaty, between the requesting country and the EU or a member state. The adequacy option is the near-twin: adequacy is a basis for transfers, but it does not make the foreign order itself enforceable.

1. Recognise the conflict: a foreign order versus GDPR duties.
2. Recall that Article 48 requires an international agreement such as an MLAT.
3. Separate a transfer mechanism (adequacy) from the enforceability of an order.

Exam tip: Foreign orders for EU personal data go through treaties (MLATs), per GDPR Article 48.

Conflicting international legislation is resolved through legal process before any technical move of data.

Two laws pull in opposite directions: US discovery wants production, and the localisation law restricts export. Moving the data satisfies one law by breaking the other, and refusing outright invites sanctions because US courts weigh foreign restrictions rather than treating them as automatic defences. The first step is legal: counsel analyses both obligations and pursues recognised channels such as the Hague Evidence Convention, letters of request or a negotiated protective order, and only then is any data moved, in the agreed form.

1. Name the two conflicting obligations.
2. Reject options that satisfy one law by breaking the other.
3. Choose the step that resolves the conflict through legal channels first.

Exam tip: When two countries' laws conflict, call counsel and use treaty channels before moving a byte.