CCSP Certified Cloud Security Professional Exam Topics and Questions

This topic sets the conceptual foundation. You need to recognise service models, deployment types, and the shared responsibility boundaries that shift depending on where you sit in the stack. The weight is moderate, but the breadth is wide: definitions, roles, reference architecture, security primitives, and design principles all appear. Candidates lose marks when they confuse provider and customer obligations or misapply a control to the wrong service layer.

– Definitions, roles and characteristics

Cloud computing definitions establish the vocabulary the exam uses without variation. You must distinguish the cloud service customer, provider, partner, broker, and regulator by their contractual and operational boundaries. Key characteristics include on-demand self-service, broad network access, multi-tenancy, rapid elasticity, resource pooling, and measured service. Each characteristic has a security implication: multi-tenancy introduces isolation risk, resource pooling complicates data residency, measured service enables cost anomaly detection. Building block technologies cover virtualisation, storage, networking, databases, and orchestration. Know what each block contributes to the service and where it sits in the stack, because questions will ask which layer owns a given control.

– Reference architecture and service models

Cloud computing activities, service capabilities, and service categories form the reference architecture. Application, platform, and infrastructure capability types map to SaaS, PaaS, and IaaS. Deployment models include public, private, hybrid, community, and multi-cloud. Each model shifts the threat surface and the compliance burden. Shared considerations span interoperability, portability, reversibility, availability, security, privacy, resiliency, performance, governance, maintenance and versioning, SLAs, auditability, regulatory obligations, and outsourcing. Every consideration has a contractual and a technical dimension. Related technologies such as machine learning, artificial intelligence, blockchain, IoT, containers, quantum computing, edge computing, confidential computing, and DevSecOps introduce new attack patterns and new control requirements. The exam tests whether you can identify which consideration or technology changes the risk profile of a given scenario.

– Security concepts and design principles

Cryptography and key management, identity and access control (user, privilege, and service access), data and media sanitisation (overwriting, cryptographic erase), network security (network security groups, traffic inspection, geofencing, zero trust), and virtualisation security (hypervisor, container, ephemeral computing, serverless) are the security concepts relevant to cloud. Common threats and security hygiene (patching, baselining) complete the list. Design principles include the cloud secure data lifecycle, cloud-based BC and DR planning, business impact analysis (cost-benefit, ROI), functional security requirements (portability, interoperability, vendor lock-in), security considerations and responsibilities across SaaS, IaaS, and PaaS, cloud design patterns (SANS principles, Well-Architected Framework, CSA Enterprise Architecture), and DevOps security. The final sub-topic covers evaluating providers against criteria such as ISO/IEC 27017 and PCI DSS, and checking for system certifications like Common Criteria and FIPS 140-2. The design questions test whether you can match a control to the correct service model and deployment type.

How Cloud Concepts, Architecture and Design is tested

At seventeen percent, this topic appears in roughly one question in six. Items present a scenario involving a service model or deployment type and ask which party holds a given responsibility, or which control applies at which layer. You are expected to recognise the boundary between customer and provider without being told explicitly. Another common pattern describes a design requirement, such as portability or reversibility, and asks which architectural choice satisfies it. Candidates lose marks when they apply an IaaS control to a SaaS environment, or when they confuse interoperability with portability. The exam also tests whether you can identify the security implication of a cloud characteristic: a question might describe rapid elasticity and ask what risk it introduces. Read the service model carefully, map it to the shared responsibility model, and check which layer the question is asking about before selecting an answer.

Data security carries the highest weight in the outline, and the depth reflects that. You move from lifecycle phases and dispersion concepts through storage architecture, encryption, key management, discovery, classification, rights management, retention, auditability, and AI dataset protection. Every sub-topic has a control or a process attached, and the exam will ask you to choose the right one for a stated objective. The cost comes when you confuse a technology (tokenisation, masking, hashing) with its use case, or when you apply a data deletion mechanism that fails to meet a legal or contractual obligation.

– Data concepts and storage architecture

Cloud data lifecycle phases (create, store, use, share, archive, destroy) define the points at which controls apply. Data dispersion describes how a single logical object may be fragmented across jurisdictions, complicating residency and sovereignty. Data flows map the movement of data between services, accounts, and networks. Storage types include long-term, ephemeral, and raw storage, each with distinct threats: ephemeral storage may persist beyond instance termination, long-term storage may lack encryption at rest, raw storage may bypass logging. Designing storage architecture means matching the storage type to the data classification and applying the corresponding controls at the correct lifecycle phase.

– Data security technologies and discovery

Encryption and key management, hashing, data obfuscation (masking, anonymisation), tokenisation, data loss prevention, and secrets management are the technologies you apply to protect data in transit, at rest, and in use. Each has a distinct purpose: encryption provides confidentiality, hashing provides integrity, tokenisation provides a non-reversible substitute, masking allows safe use in non-production environments. Data discovery distinguishes structured, unstructured, and semi-structured data, and identifies data location. The exam tests whether you can select the technology that satisfies a stated requirement, such as allowing analytics on sensitive data without exposing the original values, or proving data has not been altered.

– Classification, rights management and retention

Data classification policies, data mapping, and data labelling establish the metadata that drives access decisions and retention rules. Information Rights Management objectives include data rights, provisioning, and access models, supported by tools for issuing and revoking certificates. Retention policies, deletion procedures and mechanisms, archiving procedures and mechanisms, and legal hold requirements define how long data persists and how it is disposed of. The exam asks which deletion mechanism satisfies a regulatory or contractual standard, and whether a proposed retention period meets the stated obligation. Confusing deletion with archiving, or applying cryptographic erase where physical destruction is required, costs marks.

– Auditability and AI data protection

Auditability, traceability, and accountability require defining event sources and event attributes (identity, IP address, geolocation), then logging, storing, and analysing data events. Chain of custody and non-repudiation ensure that evidence remains admissible. AI and machine learning introduce dataset and model privacy concerns, plus dataset and model security requirements such as validation and verification. Poisoned training data or adversarial inputs can compromise model integrity, and the exam tests whether you recognise the control that mitigates the risk without disrupting the learning process.

How Cloud Data Security is tested

Twenty percent of the exam comes from this topic, making it the heaviest single section. Items describe a data protection requirement or a regulatory obligation and ask which technology, process, or lifecycle control satisfies it. You must distinguish encryption from hashing, masking from tokenisation, deletion from archiving, and classification from labelling. Another pattern presents a data discovery scenario and asks which data type or location applies. Candidates lose marks when they select a technology that provides the wrong property: choosing hashing when confidentiality is required, or choosing masking when non-repudiation is needed. The AI sub-topics are newer and test whether you can identify a dataset integrity risk or a model validation failure. Read the requirement first, identify the security property it demands, then match the property to the technology. Do not rely on keyword matching alone.

Infrastructure and platform security pulls you down to the physical environment, the network, compute, virtualisation, storage, and the management plane. From there you design a secure data centre (logical, physical, environmental, resilient), analyse infrastructure risks, plan and implement controls, and prepare BC and DR plans. The topic is seventeen percent by weight, the same as the first, but the focus is narrower: you need to know which control applies at which layer and how resilience is achieved without introducing new risk.

– Infrastructure components and data centre design

Cloud infrastructure and platform components include the physical environment, network and communications, compute, virtualisation, storage, and the management plane. Each component has a security perimeter and a set of controls. Designing a secure data centre involves logical design (tenant partitioning, access control), physical design (location, buy or build decision), environmental design (HVAC, multi-vendor pathway connectivity), and resilient design. Logical partitioning prevents tenant crossover, physical location affects jurisdiction and threat exposure, environmental controls prevent outages, and resilience ensures availability under failure conditions. The exam tests whether you can identify the design choice that satisfies a stated security or availability requirement without violating another.

– Risk analysis and security controls

Risk assessment includes identification and analysis of cloud vulnerabilities, threats, and attacks, followed by risk mitigation strategies. Planning and implementing security controls means applying physical and environmental protection (on-premises), system, storage and communication protection, identification, authentication and authorisation in cloud environments, and audit mechanisms (log collection, correlation, packet capture). Each control has a scope: physical controls apply on-premises or at the provider's facility, system controls apply to compute and storage, audit mechanisms apply to the management plane and the data plane. The exam asks which control mitigates a stated risk, and candidates lose marks when they select a control that operates at the wrong layer or that the customer does not own in the given service model.

– Business continuity and disaster recovery

BC and DR planning starts with a strategy, then defines business requirements (RTO, RPO, recovery service level), and proceeds to creation, implementation, and testing of the plan. RTO is the maximum tolerable downtime, RPO is the maximum tolerable data loss, and recovery service level defines the performance and availability of the restored service. The exam tests whether a proposed BC or DR design meets the stated RTO and RPO, and whether the testing process is sufficient to validate the plan. Candidates lose marks when they confuse RTO with RPO, or when they assume replication alone satisfies a DR requirement without validating failover and failback procedures.

How Cloud Platform & Infrastructure Security is tested

At seventeen percent, this topic appears in roughly one question in six. Items describe an infrastructure component, a risk, or a resilience requirement and ask which control or design choice applies. You must know which controls the customer owns in each service model, because a control that applies in IaaS may not be available in PaaS or SaaS. Another common pattern presents RTO and RPO values and asks which BC or DR design satisfies them. Candidates lose marks when they select a control that operates at the wrong layer, or when they propose a resilience design that meets RTO but violates RPO. The audit mechanism sub-topic tests whether you can identify which logging or monitoring control provides the required visibility. Read the service model and the requirement carefully, map the control to the correct layer, and verify that the customer has the access needed to implement it.

Application security begins with training and awareness (cloud development basics, common pitfalls, OWASP Top 10, SANS Top 25), moves through the SDLC process and its application to cloud-specific risks, covers software assurance and validation, then addresses verified secure software, cloud application architecture, and IAM solutions. The weight is seventeen percent, the same as infrastructure, but the scope is the application layer and the development process. Candidates lose marks when they apply a control that belongs in infrastructure to an application-layer risk, or when they confuse static and dynamic testing.

– Training, SDLC process and application

Training and awareness covers cloud development basics, common pitfalls, and common cloud vulnerabilities such as OWASP Top 10 and SANS Top 25. The SDLC process includes business requirements and phases (design, code, test, maintain), plus methodologies (waterfall versus agile). Applying the SDLC to cloud means addressing cloud-specific risks, threat modelling (STRIDE, DREAD, ATASM, PASTA), avoiding common vulnerabilities during development, secure coding (OWASP ASVS, SAFECode), and software configuration management and versioning. Threat modelling identifies attack vectors before code is written, secure coding standards prevent injection and authentication flaws, configuration management ensures that changes are tracked and reversible. The exam tests whether you can select the correct threat modelling framework for a stated objective, or identify the SDLC phase where a given control applies.

– Software assurance, validation and verified software

Software assurance and validation includes functional and non-functional testing, security testing methodologies (blackbox, whitebox, static, dynamic, SCA, IAST), quality assurance, and abuse case testing. Static testing examines code without executing it, dynamic testing runs the application, SCA checks third-party components, IAST combines static and dynamic analysis. Using verified secure software means securing APIs, supply-chain management (vendor assessment), third-party software management (licensing), and validated open-source software. The exam asks which testing methodology detects a stated vulnerability type, and candidates lose marks when they choose static analysis for a runtime flaw or dynamic analysis for a design-time issue.

– Cloud application architecture and IAM

Cloud application architecture includes supplemental security components (WAF, DAM, XML firewalls, API gateway), cryptography, sandboxing, and application virtualisation and orchestration (microservices, containers). Each component provides a layer of defence: WAF filters HTTP attacks, DAM monitors database queries, API gateway enforces rate limits and authentication. IAM solutions cover federated identity, identity providers, single sign-on, multi-factor authentication, CASB, and secrets management. Federated identity allows cross-domain authentication, SSO reduces credential sprawl, MFA adds a second factor, CASB enforces policy between users and cloud services. The exam tests whether you can select the IAM pattern that satisfies a stated access requirement, and whether you recognise which supplemental component mitigates a given application-layer threat.

How Cloud Application Security is tested

Seventeen percent of the exam comes from this topic. Items describe an application security requirement, a development phase, a vulnerability, or an access scenario and ask which control, testing method, or IAM pattern applies. You must distinguish static from dynamic testing, blackbox from whitebox, and functional from non-functional testing. Another common pattern presents a threat model and asks which framework applies, or describes an application architecture and asks which supplemental component is needed. Candidates lose marks when they confuse testing methodologies, or when they apply an infrastructure control to an application-layer risk. The IAM questions test whether you can match a federated identity pattern or an MFA implementation to a stated requirement. Read the scenario carefully, identify whether the risk is at design time, code time, or runtime, then select the control or testing method that operates at that point.

Operations covers building and maintaining physical and logical infrastructure, implementing operational controls and standards (ITIL, ISO/IEC 20000-1), supporting digital forensics, managing communication with vendors and other parties, and managing security operations (SOC, monitoring, log analysis, vulnerability assessments). The weight is sixteen percent, and the scope is the day-to-day running of the environment. Candidates lose marks when they confuse change management with configuration management, or when they propose a forensic collection method that violates chain of custody.

– Building and maintaining infrastructure

Building physical and logical infrastructure means configuring hardware-specific security requirements (HSM, TPM), installing and configuring management tools, configuring virtual hardware (network, storage, memory, CPU, hypervisor type 1 and 2), and installing guest OS virtualisation toolsets. Maintaining infrastructure includes access controls for local and remote access (RDP, secure terminal access, SSH, console-based mechanisms, jumpboxes, virtual client), secure network configuration (VLAN, TLS, DHCP, DNSSEC, VPN), network security controls (firewalls, IDS, IPS, honeypots, vulnerability assessments, network security groups, bastion host), OS hardening through baselines, monitoring and remediation (Windows, Linux, VMware), patch management, Infrastructure as Code strategy, availability of clustered hosts (distributed resource scheduling, dynamic optimisation, storage clusters, maintenance mode, high availability), availability of guest OS, performance and capacity monitoring (network, compute, storage, response time), hardware monitoring (disk, CPU, fan speed, temperature), backup and restore functions for host and guest OS, and management plane operations (scheduling, orchestration, maintenance). Each task has a security implication: improper access controls expose the management plane, missing patches introduce vulnerabilities, inadequate monitoring delays incident detection.

– Operational controls and standards

Implementing operational controls and standards means applying ITIL or ISO/IEC 20000-1 processes: change management, continuity management, information security management, continual service improvement, incident management, problem management, release management, deployment management, configuration management, service level management, availability management, and capacity management. Each process has a defined scope and a set of inputs and outputs. Change management controls modifications to the environment, incident management responds to unplanned interruptions, problem management identifies root causes, configuration management tracks the state of assets. The exam tests whether you can identify which process applies to a stated operational scenario, and candidates lose marks when they confuse incident management with problem management, or change management with configuration management.

– Forensics, communication and security operations

Supporting digital forensics includes forensic data collection methodologies, evidence management, and collecting, acquiring, and preserving digital evidence. Chain of custody and non-repudiation are required for evidence to remain admissible. Managing communication with relevant parties means engaging vendors, customers, partners, regulators, and other stakeholders at the correct point in an incident or a compliance cycle. Managing security operations includes running a SOC, intelligent monitoring of security controls (firewalls, IDS, IPS, honeypots, network security groups, AI), log capture and analysis (SIEM, log management), and vulnerability assessments. SIEM aggregates and correlates logs, AI-driven monitoring detects anomalies, vulnerability assessments identify weaknesses before they are exploited. The exam asks which forensic method preserves evidence, which communication channel applies to a stated party, and which monitoring control provides the required visibility.

How Cloud Security Operations is tested

Sixteen percent of the exam comes from this topic. Items describe an operational task, a process requirement, a forensic scenario, or a monitoring objective and ask which control, process, or tool applies. You must distinguish the ITIL processes from one another, because the exam will present a scenario that could plausibly fit two processes and ask which one governs. Another common pattern describes a forensic requirement and asks which collection method preserves chain of custody, or presents a monitoring requirement and asks which tool or control satisfies it. Candidates lose marks when they confuse incident management with problem management, or when they propose a forensic method that alters evidence. The infrastructure maintenance sub-topics test whether you can identify the correct hardening, patching, or monitoring control for a stated objective. Read the scenario, identify the process or control domain, and verify that the proposed action satisfies the requirement without introducing a new risk.

Legal, risk and compliance is the lightest topic by weight at thirteen percent, but the breadth is considerable: legal requirements and unique cloud risks, privacy issues, audit process and methodologies, implications of cloud to enterprise risk management, and outsourcing and cloud contract design. Every sub-topic involves interpreting a legal or contractual obligation and mapping it to a technical control or a process. Candidates lose marks when they confuse data owner with data custodian, or when they assume an audit scope statement grants access it does not.

– Legal requirements and privacy

Articulating legal requirements means understanding conflicting international legislation, evaluating legal risks specific to cloud computing, applying legal frameworks and guidelines, meeting eDiscovery requirements (ISO/IEC 27050, CSA Guidance), and satisfying forensics requirements. Privacy issues include the difference between contractual and regulated private data (PHI, PII), country-specific legislation related to private data, jurisdictional differences in data privacy, standard privacy requirements (ISO/IEC 27018, GAPP, GDPR), and Privacy Impact Assessments. Conflicting legislation arises when data crosses borders, and the exam tests whether you can identify which jurisdiction applies or which obligation takes precedence. Confusing PHI with PII, or assuming GDPR applies outside its territorial scope, costs marks.

– Audit process and enterprise risk management

Understanding the audit process means distinguishing internal and external audit controls, assessing the impact of audit requirements, identifying assurance challenges of virtualisation and cloud, recognising types of audit reports (SSAE, SOC, ISAE), understanding restrictions of audit scope statements, conducting gap analysis (control analysis, baselines), planning audits, evaluating the internal information security management system and controls system, reviewing policies (organisational, functional, cloud computing), identifying and involving relevant stakeholders, meeting specialised compliance requirements for highly-regulated industries (NERC/CIP, HIPAA, HITECH, PCI), and understanding the impact of distributed IT models (diverse geographical locations crossing legal jurisdictions). Enterprise risk management includes assessing provider risk management programmes (controls, methodologies, policies, risk profile, risk appetite), distinguishing data owner/controller from data custodian/processor, meeting regulatory transparency requirements (breach notification, SOX, GDPR), applying risk treatment (avoid, mitigate, transfer, share, accept), using different risk frameworks, defining metrics for risk management, and assessing the risk environment (service, vendor, infrastructure, business). The exam tests whether you can identify the correct audit report type for a stated assurance need, or which risk treatment applies to a given scenario.

– Outsourcing and contract design

Understanding outsourcing and cloud contract design means defining business requirements (SLA, MSA, SOW), managing vendors (vendor assessments, vendor lock-in risks, vendor viability, escrow), managing contracts (right to audit, metrics, definitions, termination, litigation, assurance, compliance, access to cloud/data, cyber risk insurance), and managing the supply chain (ISO/IEC 27036). SLAs define service levels, MSAs establish the overarching relationship, SOWs specify deliverables. Right to audit grants the customer access to provider controls, escrow protects against vendor failure, cyber risk insurance transfers financial risk. The exam asks which contract term satisfies a stated requirement, and candidates lose marks when they assume a term is implied when it must be negotiated explicitly.

How Legal, Risk and Compliance is tested

Thirteen percent of the exam comes from this topic, making it the lightest by weight. Items describe a legal obligation, a privacy requirement, an audit scenario, a risk management decision, or a contract term and ask which control, process, or clause applies. You must distinguish data owner from data custodian, controller from processor, internal audit from external audit, and one audit report type from another. Another common pattern presents conflicting legislation or jurisdictional differences and asks which obligation takes precedence. Candidates lose marks when they confuse privacy regulations, assume an audit scope grants access it does not, or select a risk treatment that does not match the stated risk appetite. The contract design questions test whether you recognise which term must be negotiated explicitly rather than assumed. Read the scenario, identify the legal or contractual domain, and verify that the proposed control or term satisfies the obligation without creating a new gap.