Six domains. Roughly 150 questions. Four hours. That's the CCSP exam on paper. The part you don't see until you've been through it is that the domains aren't weighted evenly, they aren't equally hard, and the one most candidates under-study is also the one that pulls the most questions.
So rather than treat this as an even walk through all six CCSP exam domains, I'm going to spend most of the time on the ones that actually move your score. If you want the flat outline, ISC2 publishes it. This is the version with opinions attached.
The Weights (and what they actually mean)
| Domain | Name | Weight |
|---|---|---|
| 1 | Cloud Concepts, Architecture, and Design | 17% |
| 2 | Cloud Data Security | 20% |
| 3 | Cloud Platform and Infrastructure Security | 17% |
| 4 | Cloud Application Security | 17% |
| 5 | Cloud Security Operations | 16% |
| 6 | Legal, Risk, and Compliance | 13% |
A few things to notice before we go further.
One in five questions comes from Domain 2. That's the single most important data point on this table. The four middle domains (1, 3, 4, 5) all cluster within a few percentage points of each other, which means obsessing over which of them is "most important" is a waste of time — they're functionally equivalent on exam day. And Domain 6 looks small, but it's where non-GRC candidates bleed the most points. More on that later.
Domain 1: Cloud Concepts, Architecture, and Design (17%)
The foundation. If the shared responsibility model isn't automatic for you by test day, Domain 1 will eat you alive — and it will also break Domains 2 through 5, because shared responsibility thinking runs through all of them.
The content itself isn't exotic. NIST SP 800-145 definitions. The three service models (IaaS, PaaS, SaaS). Deployment models — public, private, hybrid, community, multi-cloud. Reference architecture, secure design principles, and how you evaluate a CSP (standards, certifications, product attestations).
The trap is that it's tested at the edges. Who's responsible for OS patching in PaaS? For IAM policy in IaaS? For data classification in SaaS? The answers shift based on the service model, and the exam writes questions specifically designed to catch candidates who memorized the textbook matrix but never internalized the why. If you can't explain, off the top of your head, why the customer is responsible for data in every service model but the provider is responsible for physical security in every service model, you're not done with Domain 1 yet.
One more thing: the CCSP exam speaks NIST, not AWS. I've seen candidates bring years of hands-on AWS experience into the exam and lose points because they picked the answer that matched how AWS does it rather than how NIST defines it. The exam is vendor-neutral by design. When you read a question, abstract up to the NIST model first, then answer.
Domain 2: Cloud Data Security (20%)
This is the domain. If you only have time to be genuinely strong in one area, make it this one.
I'm going to spend disproportionate time here because Domain 2 is where the largest gap tends to open between candidates who pass and candidates who don't — and it's not because the material is conceptually hard. It's because it's broad, detailed, and easy to skim past if you're coming in with a technical background that treats data security as "encryption plus access control." CCSP wants more.
The lifecycle they actually test
Memorize this cold: Create, Store, Use, Share, Archive, Destroy.
That's the cloud data lifecycle. Six stages, in that order. The exam doesn't just ask you to recite it — it asks which controls apply at which stage, and the answer choices will include controls that sound plausible but belong to a different stage. Classification happens at Create. Access controls dominate Use and Share. Crypto-shredding is Destroy, not Archive. When two answers look right, the one that aligns with the correct lifecycle stage is usually the one they want.
One pattern I've noticed: candidates who've been in the field for a while tend to conflate this with older data lifecycle models (the ISO/IEC version, or the one from the CSA Security Guidance). They're related but not identical, and the CCSP exam is specifically testing the six-stage cloud version. If your study materials taught you a different sequence, override it.
For a deeper walkthrough, see our cloud data lifecycle guide.
Key management is where candidates melt
Customer-managed keys. Bring-your-own-key. Hold-your-own-key. Provider-managed keys. HSM-backed keys. Envelope encryption. The exam will test all of these, and it will test the tradeoffs — who holds the root of trust, who has operational access, what happens when you offboard.
If you can't rattle off the difference between CMEK and BYOK without looking it up, you're not ready for Domain 2. And if "HYOK" doesn't mean anything to you yet, go learn it tonight. It comes up more than you'd expect, usually in scenarios involving regulated data or sovereign cloud requirements.
Tokenization vs. masking vs. anonymization
These three come up in the same question. A lot. Candidates treat them as synonyms. They aren't.
- Tokenization replaces sensitive data with a non-sensitive token; the mapping is reversible if you control the vault.
- Masking hides data at the presentation layer (think:
****-****-****-1234on a receipt). The original data is still there. - Anonymization permanently removes identifiability. If done correctly, there's no going back.
Pseudonymization is a fourth cousin — reversible like tokenization, but with a different mechanism and a specific GDPR meaning. Don't conflate them.
Everything else in Domain 2
Cloud data storage architectures (volume, object, database, application-managed). Data discovery and classification. Rights management (IRM, DRM). Retention and deletion policies. Sanitization in cloud — which, as a reminder, usually means crypto-shredding because you don't get to physically destroy a provider's disks. Privacy frameworks in cloud contexts (GDPR, CCPA, HIPAA). Encryption at rest, in transit, in use — including homomorphic encryption and confidential computing at the conceptual level. DLP in cloud environments.
That's a lot. It's supposed to be a lot. Domain 2 is 20% of the exam for a reason.
Domain 3: Cloud Platform and Infrastructure Security (17%)
Infrastructure: the physical layer, the network layer, compute, virtualization, storage, and — the one the exam loves — the management plane.
I'll keep this shorter because most candidates with a technical background over-study Domain 3, not under-study it. If you work in cloud infra, you already know most of this.
What trips people up isn't the infrastructure itself. It's remembering that the management plane is the crown jewel. An attacker who compromises the management plane owns everything running in the account — data, compute, identity, the ability to cover their tracks by disabling logging. Whenever you see a scenario question about protecting "the most critical surface in a cloud environment," the management plane is almost always the defensible answer. IAM hardening, MFA, logging, separation of duties, privileged access workstations — that's the defensive stack the exam wants you to recognize.
Also expect conceptual questions on hypervisor attacks, VM escape, and container escape. You don't need to be able to execute them; you need to know they exist, where they fit in the threat model, and what mitigates them.
Domain 4: Cloud Application Security (17%)
This is the domain that speaks to DevSecOps practitioners, but it has a specific thing that traps candidates who come in confident: the identity protocols.
The rest of Domain 4 — secure SDLC in cloud, SAST/DAST/IAST/RASP, OWASP Cloud-Native Top 10, supply chain security, cloud-specific threat modeling — is relatively straightforward if you've worked in or around application security. But OAuth 2.0, OpenID Connect, and SAML get conflated constantly, and the exam writes questions designed to catch exactly that confusion.
The clean version:
- OAuth 2.0 is authorization. It's about delegating access — letting App A act on a user's behalf in App B without sharing credentials.
- OIDC is authentication, layered on top of OAuth 2.0. It tells you who the user is.
- SAML is an older federation protocol, typically used for web SSO in enterprise contexts.
If a question involves API authorization between services, it's OAuth 2.0. If it's about proving identity for sign-in, it's OIDC or SAML depending on the architecture. And know the token types — access, refresh, ID. The exam will drop them into answer choices interchangeably and check whether you notice.
Domain 5: Cloud Security Operations (16%)
Running it, monitoring it, responding to incidents in it. Patch management, configuration management, vulnerability management, change management, continuous monitoring, SOC operations, log management, incident response lifecycle.
The part that's genuinely harder in cloud than on-prem: digital forensics. You usually don't have physical access to the underlying hardware. Volatile data may be gone before you can capture it. Multi-tenancy raises contamination concerns. Chain of custody gets harder to prove. When a question asks about cloud forensic challenges, the correct answer usually involves one of those limitations — not a technique you'd use on a laptop sitting in front of you.
Log management across multi-cloud environments also gets tested. The issue isn't collecting logs; it's centralizing them, normalizing them, and handling the fact that log availability varies by service and by provider. Assume the exam will ask about a scenario where logs are fragmented across services and ask you to pick the right operational response.
Domain 6: Legal, Risk, and Compliance (13%)
Smallest weight. Biggest gap for technical candidates.
I worked with a candidate who was scoring above 85% on practice tests in Domains 1–5 and below 60% in Domain 6. He was a senior cloud engineer, brilliant at architecture, and he'd decided early on that "the lawyer domain" wasn't worth investing in because it was only 13% of the exam. He failed his first attempt by a margin that maps almost exactly to Domain 6 alone. Passed the retake after spending two weeks on frameworks, contracts, and privacy law.
The material isn't actually about being a lawyer. It's about being able to function in a cloud environment where the legal and compliance layer drives technical decisions. Know the difference between SOC 1, SOC 2 (Type I vs. Type II), and SOC 3 — what each one attests to and who reads it. Know ISO 27001 vs. 27017 vs. 27018 — the first is the base ISMS standard, the second is cloud-specific security controls, the third is cloud-specific privacy controls. Know CSA STAR at each level. Know what belongs in a cloud SLA, what belongs in a DPA, and what belongs in an MSA.
Also: jurisdictions. Cross-border data transfer restrictions (Schrems II, Standard Contractual Clauses, adequacy decisions). eDiscovery in cloud. These show up in scenario questions that will absolutely look like they belong to another domain until you realize the actual question is about who has legal authority over the data.
If you're coming in from a deeply technical background, budget more Domain 6 time than your gut tells you to. Not because the domain is 13% of the exam — but because you're probably going to start at 40% accuracy here and the climb from 40% to 75% takes real effort.
How the domains bleed into each other
Real exam questions often touch two or three domains at once. A question about cloud data retention might pull from Domain 2 (data security), Domain 5 (operations), and Domain 6 (legal holds and jurisdiction). A question about API security probably involves Domain 4 (application security), Domain 1 (shared responsibility for the API gateway), and Domain 2 (data in transit).
When two answer choices both look defensible, the one the exam wants is usually the one that addresses security, governance, and business risk together — not just the technical control. That's a CCSP-specific habit worth training into yourself. It's also, coincidentally, what the CCSP shares most strongly with its older sibling; if you want to see where the two overlap and diverge, our CISSP vs. CCSP breakdown covers it.
Where to focus if you're short on time
A rough prioritization if you have limited prep time and want to allocate it by expected return:
- Domain 2 — heaviest weight, broadest content, most commonly under-studied
- Domain 6 — light weight but largest gap for technical candidates
- Domain 1 — if shared responsibility isn't automatic, nothing else lands
- Domain 4 — the OAuth/OIDC/SAML cluster alone is worth focused time
- Domain 3 — mostly review for infra folks; focus on the management plane
- Domain 5 — forensics and log management in cloud are the distinctive pieces
Note that this isn't the domain weight order. Weight matters, but gap size matters more. The domains where you already know 70% of the material don't need as much time as the domains where you're starting at 40%.
Find your real gaps
Most candidates are wrong about where they're weak. The engineer who's confident about Domain 3 is usually fine there and struggling in Domain 6. The GRC person who worries about Domain 4 is usually fine there and weak in Domain 3. Your gut is not a reliable signal — data is.
If you want a fast read on where you actually stand across all six CCSP exam domains, LearnZapp has a free diagnostic that takes about 30 minutes and gives you per-domain accuracy. No signup, no commitment. It pairs with the Wiley CCSP Official Study Guide content and adaptive practice, which is what most candidates use as their primary prep.
Take the free CCSP diagnostic test
Once you know where you're actually starting from, the 10-week CCSP study plan is the next thing worth reading.