A cloud architect at your company has deployed a critical workload on a managed Kubernetes service (PaaS). They've configured strict network policies within the cluster. A high-severity vulnerability is discovered in the underlying node operating system. Who is responsible for patching it: your company or the cloud provider?
If you answered "the cloud provider" without hesitation, you're on the right track. But if a follow-up question asked who is responsible for scanning the container images for vulnerabilities before deployment, and you also said "the cloud provider," you've just hit the most common failure point in CCSP Domain 3. Understanding these precise boundaries is the difference between a pass and a fail.
Per VoraPrep's CCSP blueprint analysis, cCSP Domain 3, Cloud Platform & Infrastructure Security, tests your judgment on securing cloud components according to the shared responsibility model. Key areas include network controls (NACLs vs. Security Groups), virtualization, storage, and management plane security, with a focus on applying frameworks like the CSA CCM to practical scenarios.
Key facts
- Domain Weight
- 19% of the CCSP exam
- Passing Score
- 700 on a 1000-point scale
- Exam Format
- 125 multiple-choice questions
- Exam Duration
- 3 hours
- Official Body
- ISC2
- Pass Rate
- ISC2 does not publish official pass rates for its certifications. Anecdotal evidence from training providers suggests a pass rate around 55%.
The U.S. Bureau of Labor Statistics projects a 32% growth for information security analyst roles from 2022 to 2032, with a median pay of $120,360 per year (BLS).
Studying for CCSP? Benchmark your score in 5 minutes.
Get an instant weak-spot assessment and a custom 12-week study plan PDF generated for your exam window.
How Does the Shared Responsibility Model Really Work?
The shared responsibility model is the single most important concept in Domain 3. The exam will not ask you to recite a chart. It will present a scenario and force you to identify the line where the Cloud Service Provider's (CSP) responsibility ends and yours (the customer's) begins.
Let's walk through a realistic case.
FinOptics, a financial analytics startup, is deploying a new application. They need a web front-end, an application processing layer, and a relational database.
Step 1: The IaaS Decision (Web Front-End)
They decide to run their NGINX web servers on IaaS virtual machines for maximum control.
- Who is responsible for patching the guest operating system (Ubuntu 22.04) on the VMs? FinOptics. The CSP is only responsible for the hypervisor and the physical hardware.
- Who configures the firewall rules for port 443 on these specific VMs? FinOptics, using Security Groups.
- Who ensures the physical server hosting the VM has redundant power? The Cloud Provider.
Step 2: The PaaS Decision (Application Layer)
For the application layer, they choose a managed container orchestration service (like Azure Kubernetes Service or Amazon EKS). This is a PaaS offering.
- Who is responsible for patching the OS on the underlying worker nodes? The Cloud Provider. This is a key benefit of managed PaaS.
- Who is responsible for scanning their custom application container images for vulnerable libraries (e.g., Log4j)? FinOptics. The provider manages the platform, but you own the code and images you deploy on it.
- Who is responsible for configuring role-based access control (RBAC) within the Kubernetes cluster to limit developer access? FinOptics. This is a customer configuration responsibility.
Step 3: The SaaS Decision (Customer Data)
For customer relationship management, they subscribe to a leading SaaS CRM platform.
- Who is responsible for ensuring the CRM application itself is secure and patched? The SaaS Provider.
- Who is responsible for configuring user profiles so that sales reps cannot delete financial records? FinOptics. This is user access management and configuration, which always falls to the customer.
- Who is responsible for encrypting the customer data at rest? This is a shared responsibility. The SaaS provider offers the encryption mechanism (platform encryption). However, FinOptics is responsible for ensuring it's enabled and, if available, for using options like Customer-Managed Encryption Keys (CMEK) to meet their own compliance requirements.
This table summarizes the core divisions. Master it.
| Responsibility Aspect | IaaS (e.g., EC2) | PaaS (e.g., RDS, EKS) | SaaS (e.g., Salesforce) |
|---|---|---|---|
| Physical Infrastructure | Cloud Provider | Cloud Provider | Cloud Provider |
| Virtualization Layer | Cloud Provider | Cloud Provider | Cloud Provider |
| Operating System | Customer | Cloud Provider | Cloud Provider |
| Application Code/Images | Customer | Customer | Cloud Provider |
| Data & Content | Customer | Customer | Customer |
| Customer IAM & Access | Customer | Customer | Customer |
| Network Configuration | Customer | Customer (partially) | Cloud Provider |
Calculate Your CCSP Score & Study Hours by Domain
Adjust your practice scores across official CCSP blueprint domains to predict your pass probability and generate a domain-weighted study schedule.
Which Cloud Network Controls Should You Choose?
The CCSP exam requires you to differentiate between the two primary network filtering mechanisms in the cloud: Network Access Control Lists (NACLs) and Security Groups (SGs). They are not interchangeable.
A NACL is a firewall for your subnets. It's the first line of defense. A Security Group is a firewall for your instances (VMs, containers). It's the last line of defense.
| Feature | NACLs (Network Access Control Lists) | Security Groups |
|---|---|---|
| Scope | Subnet level | Instance level |
| State | Stateless: Return traffic must be explicitly allowed. | Stateful: Return traffic is automatically allowed. |
| Rules | Allow and Deny rules. | Allow rules only. |
| Evaluation | Rules are processed in numerical order. | All rules are evaluated before decision. |
| Use Case | Broad-stroke filtering (e.g., block a known bad IP from an entire subnet). | Granular control for specific applications (e.g., allow web traffic to web servers). |
How Do You Secure Modern Cloud Architectures?
Domain 3 goes beyond basic VMs and networks. You must understand the security principles for containers, serverless, and Infrastructure as Code.
Securing Containers and Orchestrators
Container security is a lifecycle process.- Registry: Secure the image registry with strong access controls.
- Image: Scan container images for known vulnerabilities (CVEs) before they are ever deployed. Use hardened, minimal base images.
- Runtime: Monitor running containers for anomalous behavior. Use tools that enforce security policies in real-time.
- Orchestrator (Kubernetes): Harden the orchestrator itself. Use RBAC, network policies, and pod security standards to enforce isolation and least privilege.
Serverless Function Security
For serverless (Functions as a Service), the focus shifts.- Permissions: Each function should have a unique execution role with the absolute minimum permissions required (least privilege).
- Event Source: Secure the trigger. If an S3 bucket upload triggers a function, ensure only authorized users can upload to that bucket.
- Code & Dependencies: You are responsible for the security of your code and any third-party libraries you include.
Infrastructure as Code (IaC) Security
IaC (e.g., Terraform, CloudFormation) lets you define infrastructure in text files. This is a huge security opportunity.- Linting & Static Analysis: Scan IaC templates for misconfigurations before deployment. This is a preventative control.
- Secrets Management: Never hardcode secrets (passwords, API keys) in IaC files. Use a secrets manager like AWS Secrets Manager or HashiCorp Vault.
- Drift Detection: Continuously monitor deployed infrastructure to detect manual changes that "drift" from the IaC-defined state.
Automated Guardrails: CSPM and CWPP
Two key tool categories you should know are:- Cloud Security Posture Management (CSPM): These tools continuously monitor your cloud environment for misconfigurations and compliance violations (e.g., a publicly exposed storage bucket).
- Cloud Workload Protection Platform (CWPP): These tools focus on securing the workloads themselves (VMs, containers, serverless functions) by providing capabilities like vulnerability scanning, runtime protection, and integrity monitoring.
What Key Frameworks and Standards Apply?
You don't need to memorize these frameworks, but you must understand their purpose and how they apply to cloud infrastructure.
NIST SP 800-53
This is a comprehensive catalog of security and privacy controls for all U.S. federal information systems. For the CCSP, you should recognize control families relevant to infrastructure, such as Access Control (AC), System and Communications Protection (SC), and Configuration Management (CM).CSA Cloud Controls Matrix (CCM)
The CCM is a cybersecurity control framework specifically for cloud computing, created by the Cloud Security Alliance. It maps its controls to other major standards (like ISO 27001 and NIST 800-53), providing a meta-framework for assessing cloud provider security.ISO/IEC 27001 and FedRAMP
- ISO/IEC 27001: A standard for an Information Security Management System (ISMS). A cloud provider with this certification demonstrates a formal, risk-based approach to security management.
- FedRAMP: A U.S. government program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.
How to Use This Cheat Sheet
- Pre-Study Overview: Read this before you start Domain 3 to frame the key concepts.
- Weekly Review: Spend 15 minutes each week reviewing the tables and exam traps. Spaced repetition is key.
- Practice Warm-up: Before a block of VoraPrep practice questions on Domain 3, scan this sheet to prime your brain.
- Gap Analysis: If you miss a question, come back here. Can you trace your mistake to a rule or trap listed on this page? If so, you've found a weak spot to target. VoraPrep's adaptive learning engine does this for you automatically.