Cloud Platform & Infrastructure Security
Decompose the platform into six layers, then secure each one on purpose
Picture a single tenant's workload as a stack that runs from the data-center floor upward: a physical environment (building, power, cooling), a network and communications fabric, pooled compute, the virtualization layer that slices that compute into shareable units, a storage tier, and a management plane that operates all of it. That six-layer decomposition is the one mental model this whole domain hangs on, because the threats and the controls are different at every layer, and the line dividing your job from the provider's moves layer by layer with the service model (IaaS, PaaS, SaaS). The classic exam trap is reasoning about "the cloud" as one undifferentiated thing and then placing a control at the wrong layer: hardening a guest operating system you no longer own under SaaS, or trusting a physical fence to stop a tenant-to-tenant data leak that only software isolation can prevent. Name the layer a scenario targets first, and the right control almost always follows.
The domain unfolds in five steps: know the layers, design the facility, rate the risk, plan the controls, plan the recovery
Read this page as the map, then follow the five subtopics in order. Cloud Infrastructure & Platform Components inventories the six layers and explains why the management plane is the highest-value target. Secure Data Center Design then asks where and how the facility itself is built, reasoning along four independent axes (logical isolation, physical site, environmental survival, and resilience). Cloud Infrastructure Risk Analysis turns those exposures into a ranked, defensible list by estimating likelihood times impact and choosing a treatment for each. Security Controls Planning selects the controls that act on the top risks, classifying every control by what it does (preventive, detective, corrective) and where it lives (physical, technical, administrative). Business Continuity & DR closes the loop for the risks you cannot prevent, sizing recovery by RTO (recovery time objective), RPO (recovery point objective), and RSL (recovery service level), and proving the plan by testing it. Each subtopic carries the mechanisms, the numbers, and the traps; this overview only shows how they chain together.
When the layers are shared, isolation is the control the exam rewards
The one instinct that carries across this whole domain is that the cloud's defining feature, multi-tenancy, is also its defining risk: compute, storage, and network are pooled and partitioned among strangers in software, so the failures that matter most are the ones that cross a software boundary you cannot see. A hypervisor escape reaches a neighbor's virtual machine, a container breakout reaches the host kernel, and a compromised management plane can reach every tenant at once. So when two answers both technically work, the exam-correct one is usually the choice that strengthens isolation and least privilege at the shared layer rather than adding a control at a layer the provider already owns. Reach for tenant partitioning, per-tenant keys, and tightly scoped access to the management plane before you reach for anything that assumes you control the floor.
How the five subtopics chain across the platform lifecycle
| Step | Question it answers | Core idea | Drill into |
|---|---|---|---|
| Know the layers | What am I securing, and whose job is it? | Six component layers; the boundary shifts by service model | Cloud Infrastructure & Platform Components |
| Design the facility | Where and how is it built? | Four independent axes: logical, physical, environmental, resilience | Secure Data Center Design |
| Rate the risk | What can go wrong, and how badly? | Likelihood times impact, ranked and given a treatment | Cloud Infrastructure Risk Analysis |
| Plan the controls | What do I put in place, and of what kind? | Function (preventive/detective/corrective) and nature (physical/technical/administrative) | Security Controls Planning |
| Plan the recovery | How do I survive what I cannot prevent? | RTO, RPO, RSL sized from the BIA, then tested | Business Continuity & DR |