Printable reviewAugust 2026 outlineSix domains

CCSP cram sheet

Use this as a last-mile cloud-security reasoning sheet after full study. It condenses responsibility boundaries, data controls, architecture, application security, operations, legal and risk distinctions, and high-value exam checks.

Independent Zeph Tech study material. Not affiliated with or endorsed by ISC2. No recalled, leaked, copied, or live-exam questions.

Study guide Practice test

Current reviewed record

Check the August 2026 owner-published facts before exam day.

Use the registry summary for current timing, item policy, domain weights, experience rules, maintenance requirements, and official ISC2 links. Do not rely on old CCSP pages that still describe the earlier 150-question/four-hour format or previous domain weighting.

Active

Exam: CCSP
Version: current outline effective August 1, 2026
Questions: 100–150 items
Item types: multiple-choice, advanced item types
Time: 180 minutes
Passing score: 700 out of 1000 points
Recommended background: Designed for experienced cloud and cybersecurity practitioners responsible for cloud architecture, data, platforms, applications, operations, risk, and compliance.
Renewal: Three-year certification cycle with 90 CPE credits required; ISC2 members holding CCSP currently pay a single U.S. $135 annual maintenance fee.

Last verified: 2026-10-01

Next review: 2026-11-01

Official certification page · Official exam objectives

Published domain weighting

Cloud Concepts, Architecture and Design17%
Cloud Data Security20%
Cloud Platform & Infrastructure Security17%
Cloud Application Security16%
Cloud Security Operations17%
Legal, Risk and Compliance13%

Domain 1 — Cloud Concepts, Architecture and Design

Start with service model and deployment model; responsibility changes by layer and service.
Shared responsibility does not mean shared equally. Verify the actual provider/customer boundary for the selected service.
Threat-model assets, trust boundaries, identities, management planes, data flows, dependencies, and abuse cases.
Resilience requires failure-domain and dependency analysis, not just duplicate instances.
Portability = ability to move; interoperability = ability to work together. Proprietary services can affect both.
Secure design still relies on least privilege, defense in depth, secure defaults, isolation, separation of duties, and fail-safe behavior.
Cloud migration is a redesign opportunity. Do not lift an unsafe trust model unchanged because the hosting platform changed.

Domain 2 — Cloud Data Security

Identify owner, classification, purpose, location, flow, access, retention, and applicable obligations before choosing a control.
Encryption protects confidentiality; key lifecycle determines whether that protection remains trustworthy.
Masking, tokenization, anonymization, encryption, and access control solve different data-exposure problems.
Backups, replicas, exports, analytics copies, and support copies belong in the data lifecycle too.
Private-by-default storage plus policy guardrails and drift detection reduce accidental exposure.
Retention should satisfy business/legal need without preserving sensitive data indefinitely.
Disposal should be approved, appropriate to the storage model, and evidenced.

Domain 3 — Cloud Platform & Infrastructure Security

Protect the management plane: dedicated admin identities, strong MFA, least privilege, controlled elevation, protected logs, emergency access.
Segmentation reduces reachability and blast radius; verify effective paths rather than trusting diagrams.
Workload identities need narrow scopes and lifecycle controls just like human identities.
Managed Kubernetes still requires customer decisions around identities, admission, images, secrets, network policy, and workload configuration.
Encryption at rest does not replace authorization, network controls, key governance, backup security, or monitoring.
Harden templates and infrastructure definitions so secure defaults are repeatable.
Trace shared provider, region, identity, key, network, and automation dependencies before claiming resilience.

Domain 4 — Cloud Application Security

Security begins with requirements and architecture, not the final production scan.
Threat-model APIs, identities, dependencies, CI/CD, secrets, functions, queues, storage, registries, and third-party services.
SAST, DAST, SCA, review, fuzzing, and penetration testing answer different assurance questions.
Secure APIs enforce authentication, authorization, input handling, rate/resource limits, logging, and safe error behavior.
Protect source control, build systems, deployment credentials, package sources, artifact integrity, and provenance.
Serverless and ephemeral workloads still need identity, logging, dependency, secrets, and authorization controls.
AI-generated code remains subject to the same review, testing, provenance, and deployment controls.

Domain 5 — Cloud Security Operations

Inventory matters because cloud resources can be created and destroyed quickly.
Centralize identity, control-plane, workload, network, key, data-access, and security telemetry where appropriate.
Preserve evidence before destructive action when doing so does not create unacceptable risk.
Stolen credentials require session/identity containment, scope analysis, activity review, rotation, and policy review—not merely instance deletion.
Emergency changes need post-event review, documentation, verification, and removal of temporary exposure.
Backups are useful only when restoration is tested with dependencies and meets business objectives.
Recovery includes identity, DNS, keys, network policy, data, secrets, monitoring, and provider dependencies—not just application images.

Domain 6 — Legal, Risk and Compliance

Provider compliance evidence has scope. It does not automatically prove customer compliance.
Map data flows, jurisdictions, processing purposes, providers, subprocessors, and obligations before selecting privacy controls.
Contracts can define security, audit, notification, cooperation, service-level, deletion, portability, and exit obligations.
Outsourcing operations does not automatically outsource accountability or risk ownership.
Concentration, lock-in, provider failure, service discontinuation, jurisdiction, and supply-chain dependencies belong in cloud risk analysis.
Verify audit-report period, covered services, exclusions, complementary customer controls, and exceptions.
Plan exit before dependency becomes a crisis: data export, deletion evidence, identities, keys, configuration, integrations, and continuity.

High-value CCSP distinctions

Provider responsibility vs customer responsibility: identify the service and layer. A provider may secure physical infrastructure while the customer still controls tenant identities, data, workload configuration, application authorization, and many logging or retention decisions.

Compliance evidence vs compliance outcome: an audit report or certification can support due diligence but has defined scope. The customer still needs evidence for its own controls and must verify that the provider evidence covers the service, period, and obligations relevant to the workload.

Encryption vs key management: encryption protects data only while the keys, access paths, rotation, revocation, backup, and recovery processes remain trustworthy. A strong algorithm with uncontrolled key access is not a complete solution.

Masking vs tokenization vs anonymization: masking hides or substitutes displayed values, tokenization replaces sensitive values with references, and anonymization aims to prevent re-identification. Choose based on purpose and reversibility requirements rather than treating them as synonyms.

Availability zone vs region: zones can reduce some local failure risks, but shared regional services or management dependencies may remain. Multi-zone does not automatically mean multi-region or independence from common services.

Vulnerability scanning vs configuration monitoring: vulnerability tools look for known weaknesses; configuration monitoring looks for insecure or drifting settings. Cloud posture requires both vulnerability and configuration evidence.

Incident containment vs evidence preservation: disable or restrict compromised capability quickly when necessary, but do not destroy logs, snapshots, session information, or API history before collection if preservation can occur safely.

Portability vs interoperability: portability concerns moving workloads or data between environments. Interoperability concerns systems working together. A design can be interoperable yet difficult to migrate, or portable yet poorly integrated.

Shared-responsibility checklist

For every scenario, ask who owns the physical facility, hypervisor, network infrastructure, operating system, runtime, application, identity service, tenant configuration, workload identity, data, encryption keys, logs, backup, retention, and incident response. Do not assume the answer from the word “cloud.”

Then identify which responsibilities are delegated but still need customer assurance. A managed service may operate patching or backups, yet the customer may still have to configure retention, validate recovery, monitor provider evidence, control identities, and decide whether the service meets business and regulatory requirements.

Finally, identify the dependency that could invalidate the control. MFA can be strong while break-glass access is unmanaged. Backups can exist while key recovery is impossible. Multi-zone deployment can exist while DNS or identity is a single point of failure. A cloud control should be evaluated as part of the service architecture, not as an isolated checkbox.

Scenario decision checklist

What cloud service and deployment model is involved?
Which party controls the affected layer?
What asset or business objective is at risk?
What data classification and processing purpose apply?
Which identity or administrative path can change the state?
Which evidence proves the current condition?
Is the problem architecture, configuration, application logic, operations, contract, or law?
What lifecycle stage is the scenario in: design, deployment, operation, incident, recovery, retention, or exit?
Does the proposed action preserve necessary evidence and reversibility?
What shared dependency or third party could defeat the apparent control?
Does the provider evidence cover this service and this customer responsibility?
Which qualifier—FIRST, BEST, MOST, PRIMARY, LEAST—changes the expected answer?

Exam-day and last-mile review

Read the service model and responsibility boundary before choosing a control. If the scenario involves SaaS, a customer may not be able to patch the underlying operating system; the better action may involve tenant configuration, identity, provider assurance, contractual escalation, or a compensating control. If the scenario involves IaaS, the customer may own far more of the workload stack.

When several answers improve security, select the one that directly addresses the stated objective at the correct layer and lifecycle stage. A broad cloud product is not automatically better than a narrow governance, identity, data, or configuration action.

When the scenario mentions legal, privacy, or regulatory requirements, identify the applicable source and scope before applying a generic security control. Technical safeguards support compliance, but they do not create a legal basis, define jurisdiction, or replace a required contract.

For incidents, preserve identity and control-plane evidence. For data, trace copies and retention. For architecture, look for common dependencies. For applications, include the pipeline and workload identity. For operations, test recovery with dependencies. For contracts, include notification and exit.

Do not use a practice score as a pass guarantee. Verify current exam logistics directly with ISC2 before your appointment, especially because the CCSP outline changed in August 2026 and older online material may still describe the prior format.

Take the practice test Return to the study guide