Cloud Infrastructure & Platform Components

The six component layers of a cloud platform

Picture a tenant clicking "launch" in a provider portal. That one action reaches down through six distinct layers, and CCSP asks you to name them because each layer is secured by a different control set and owned by a different party. From the floor up, the layers are the physical environment, network and communications, compute, virtualization, storage, and the management plane. The ISC2 CCSP exam outline^[1] lists these exact six under objective 3.1, and the cloud reference model in NIST SP 800-145^[2] frames why they exist: resource pooling and rapid elasticity require a stack that abstracts shared hardware into on-demand, multi-tenant services.

The physical environment is the data-center building itself: power, cooling, cabling, and physical access control. The network and communications layer is the fabric that carries tenant traffic between components, increasingly software-defined so that segmentation and routing are configured rather than cabled. Compute is the pooled CPU and memory that actually run workloads. Virtualization is the hypervisor or container runtime that carves that pooled compute into isolated, shareable units so many tenants safely share one physical host. Storage is the pooled persistent and ephemeral data tier. The management plane is the orchestration and administration layer (the portal, the cloud APIs, the hypervisor management consoles, the orchestration tooling) that provisions, configures, moves, and destroys everything in the five layers beneath it.

The practical skill is layer placement. When a stem describes a problem, locate it in exactly one layer first, because that decision drives which control and which owner are correct. A leaked snapshot is a storage-layer concern; a guest reaching the host kernel is a virtualization-layer concern; an exposed admin API key is a management-plane concern. Get the layer wrong and you will reach for the wrong control.

The five stacked layers run from the physical floor up to storage; the management plane spans them all because it provisions and operates every layer. Model: ISC2 CCSP objective 3.1.

Compute, virtualization, and storage: pooling makes isolation the control

Resource pooling is the defining trait of these three layers, and isolation is the security property that pooling puts at risk. The provider takes physical CPU, memory, and disks and shares them across many unrelated tenants, so the central question at every one of these layers is the same: can one tenant reach another tenant's resources?

Compute and virtualization

Compute is the raw pooled CPU and memory; virtualization is the boundary that makes sharing it safe. A hypervisor is software that runs multiple virtual machines on one physical host and keeps each VM's memory and CPU state separate. Two types matter for the exam: a Type 1 (bare-metal) hypervisor runs directly on the hardware and is what providers use for production multi-tenancy because it has a smaller attack surface, while a Type 2 (hosted) hypervisor runs as an application on top of a host operating system and is typical of desktop or lab use. Containers are the lighter-weight alternative: they share the host kernel and isolate at the process and namespace level rather than virtualizing hardware, which makes them faster to start but gives them a weaker isolation boundary than a VM, because a kernel vulnerability is shared by every container on the host.

The headline threat at this layer is VM escape (also called hypervisor escape): a guest breaks out of its virtual machine and executes on the underlying host or hypervisor, which would let it reach co-resident tenants. The container analogue is container escape to the shared kernel. Both defeat multi-tenant isolation entirely, which is why hardening the hypervisor and patching it promptly is a top control. A related, subtler risk is the side-channel attack, where a malicious workload co-resident on the same physical host infers another tenant's data from timing, cache, or power behavior rather than breaking isolation outright.

Storage

Storage is pooled the same way, so it has the same family of risks expressed in data terms. Data remanence is the storage-layer parallel to a leaked resource: residual data left on physical media after it is released, which a later tenant could recover if the provider reassigns that capacity without sanitizing it. The cloud answer is twofold. Encrypting tenant data at rest means leftover bytes are useless without the key, and cryptographic erase (destroying the encryption key) instantly renders all that data unrecoverable, which scales far better than physically overwriting shared media; both techniques appear in NIST SP 800-88 on media sanitization^[3]. The other classic storage failure is exposure rather than remanence: an object store left publicly readable, or a volume created without encryption.

VMs isolate at the hypervisor (strong); containers share the host kernel (weaker, faster). Both place tenant isolation at the virtualization layer.

Why the management plane is the apex target

If you remember one thing from objective 3.1, make it this: the management plane is the single most valuable target in a cloud platform, because it controls every other layer at once. The management plane is the orchestration and administration layer (the provider web portal, the cloud control APIs, the hypervisor and orchestration consoles) used to provision, configure, snapshot, relocate, and destroy resources. An attacker who never touches a guest operating system, never exploits a hypervisor, and never breaks storage isolation can still copy every snapshot, recreate every key, and delete every workload if they hold a privileged management-plane credential. That breadth is exactly why CCSP elevates it above the technically harder attacks on the layers below.

The practical consequence is that management-plane access deserves controls disproportionate to any single workload. The core set is consistent across providers and frameworks: enforce multi-factor authentication on every administrative identity so a stolen password alone is not enough; apply least privilege and role separation so no one account can both configure and audit; route all administrative sessions through a hardened bastion host (jump host) rather than exposing consoles directly to the internet; and log every privileged action to an append-only store for detection and forensics. These map directly to the access-control and audit families in NIST SP 800-53^[4], specifically the AC (access control) and AU (audit and accountability) families.

The reason the management plane concentrates risk is the cloud's own design. A traditional data center forces an attacker to be physically present or pivot host by host; the cloud collapses that into an API call. The same elasticity that lets a tenant create a thousand servers in a minute lets a compromised admin destroy them just as fast, so the blast radius of a management-plane breach is the entire estate, not one machine.

Admin access is gated by MFA and a bastion host; the management plane then provisions all lower layers, so one privileged credential reaches the entire estate.

Exam-pattern recognition for component layers

Domain 3.1 items are almost always a layer-identification or an ownership question wearing a scenario. Train two reflexes and most of them resolve quickly.

Reflex one: name the layer, then the control

The stem describes a symptom; you locate the layer; the layer dictates the control. "A departing tenant's deleted volume is reassigned and the new tenant recovers old files" is storage / data remanence, so the answer is encryption with cryptographic erase, not a network firewall. "A guest VM executes code on the hypervisor host" is virtualization / VM escape, so the answer is hypervisor hardening and patching, not data classification. "An attacker uses leaked API keys to snapshot and exfiltrate every database" is management plane, so the answer is MFA, least privilege, and privileged-action logging, not host antivirus. When two options both sound plausible, the one that matches the layer the symptom lives in is correct; the distractor usually borrows a real control from the wrong layer.

Reflex two: map the component to its owner by service model

The shared-responsibility line moves with the service model, and the exam tests whether you know where it sits. Under IaaS the provider owns the physical, network, and virtualization host layers while the customer owns the guest OS, its patching, and everything above. Under PaaS the provider additionally owns the operating system and runtime, leaving the customer the application and its data. Under SaaS the provider owns everything down to the application, and the customer owns only their data, their access configuration, and their identities. So "who patches the guest OS" is the customer under IaaS but the provider under PaaS and SaaS; "who secures the hypervisor" is always the provider in public cloud. A question that names a component and a service model is asking you to find the intersection.

Distractor patterns to expect

Watch for an answer that is a genuine control but aimed at the wrong layer (a firewall offered for a data-remanence problem), an answer that assigns provider-owned infrastructure to the customer ("the customer should harden the hypervisor" in public cloud, which the customer cannot even reach), and an answer that treats containers and VMs as equally strong isolation when the question hinges on the container's shared-kernel weakness.

Shared responsibility by service model: the customer-owned band shrinks from IaaS to PaaS to SaaS while the provider owns more of the lower layers.

The six cloud component layers: what each is and its signature concern

Component layer	What it is	Vendor examples	Signature security concern
Physical environment	The data-center building, power, cooling, and physical access controls beneath everything else	Provider regions, availability zones, and on-site security	Physical breach, environmental failure, and disposal of failed media
Network and communications	The fabric that connects components and carries tenant traffic, including software-defined networking	VPC / VNet / VPC networks, load balancers, software-defined networking	East-west lateral movement, traffic interception, and missing segmentation
Compute	The pooled CPU and memory that run workloads, allocated on demand	Physical hosts behind EC2 / Azure VMs / Compute Engine	Resource exhaustion, side-channel leakage between co-resident workloads
Virtualization	The hypervisor or container runtime that divides compute into isolated, shareable units for multiple tenants	Hypervisors (Type 1/Type 2), container runtimes, serverless platforms	VM escape, container escape, and hypervisor compromise breaking tenant isolation
Storage	The pooled persistent and ephemeral data tier shared across tenants	Block, object, and file storage offered by the provider	Data remanence, unencrypted volumes, and exposed object stores
Management plane	The orchestration and administration layer that provisions and operates every other layer	Provider portal, cloud APIs, hypervisor management consoles, orchestration tooling	Privileged-credential compromise that controls all other layers at once

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A cloud platform has six component layers; name the layer before the control

CCSP objective 3.1 breaks every cloud platform into six layers: physical environment, network and communications, compute, virtualization, storage, and the management plane. Each layer has its own threats and controls, so the first move on a Domain 3 stem is to place the symptom in exactly one layer, because that decides which control and which owner are correct. Misplacing the layer is what leads to picking a real but wrong-layer control.

The management plane is the highest-value target because it controls every other layer

The management plane is the orchestration and administration layer (provider portal, cloud APIs, hypervisor and orchestration consoles) that provisions, configures, snapshots, moves, and destroys all other resources. A single privileged credential here lets an attacker copy every snapshot or delete the whole estate without ever touching a guest OS or breaking a hypervisor, so its blast radius is the entire environment. That breadth is why CCSP elevates it above the technically harder attacks on lower layers.

Trap Assuming the hardest attack (VM escape, hypervisor compromise) is the biggest risk; the management plane is more dangerous because it reaches every layer at once through ordinary API calls.

4 questions test this

Protect the management plane with MFA, least privilege, a bastion host, and full logging

Because management-plane access reaches the whole estate, it gets controls out of proportion to any single workload: enforce multi-factor authentication on every admin identity, separate roles so no account can both configure and audit, route administrative sessions through a hardened bastion (jump) host instead of exposing consoles to the internet, and log every privileged action to an append-only store. These map to the access-control (AC) and audit (AU) families of NIST SP 800-53.

2 questions test this

Virtualization is the boundary that makes multi-tenancy safe

Compute, virtualization, and storage are pooled and shared across unrelated tenants, so the core security question at these layers is whether one tenant can reach another's resources. Virtualization (a hypervisor isolating virtual machines, or a runtime isolating containers) is the boundary that keeps co-resident tenants apart, so isolation is the central control. When a stem raises one tenant reaching another's compute, the fix lives at the virtualization layer, not at a network firewall.

4 questions test this

VM escape breaks tenant isolation, so harden and patch the hypervisor

A VM escape (hypervisor escape) is a guest breaking out of its virtual machine to run on the underlying host or hypervisor, which would let it reach co-resident tenants and defeat multi-tenant isolation entirely. The container analogue is a container escape to the shared kernel. The defense is hypervisor hardening and prompt patching, which is why the provider, not the customer, owns hypervisor security in public cloud.

Trap Reaching for a network firewall or security group to contain a VM escape; the breach is at the virtualization layer, so the answer is hypervisor hardening and patching, not network filtering.

11 questions test this

Type 1 hypervisors run on bare metal; Type 2 run on a host OS

A Type 1 (bare-metal) hypervisor runs directly on the hardware and is what cloud providers use for production multi-tenancy because it has a smaller attack surface. A Type 2 (hosted) hypervisor runs as an application on top of a host operating system and is typical of desktop or lab use, where the host OS adds attack surface beneath the guests.

Trap Assuming providers run production tenants on Type 2 hypervisors; bare-metal Type 1 is preferred for multi-tenancy because there is no host OS layer to compromise.

3 questions test this

Containers share the host kernel, a weaker boundary than a VM

Containers isolate at the process and namespace level and share the host kernel, which makes them faster to start than virtual machines but gives them a weaker isolation boundary, because a single kernel vulnerability is exposed to every container on that host. A VM carries its own guest OS and is isolated by the hypervisor, so it survives a kernel flaw that would compromise neighboring containers.

Trap Treating a container and a VM as equally strong isolation; the container's shared kernel is a single shared fault domain that a VM's hypervisor boundary does not have.

8 questions test this

Side-channel attacks infer data without breaking isolation

A side-channel attack lets a workload co-resident on the same physical host infer another tenant's data from timing, cache, or power behavior rather than breaking the isolation boundary outright. It is a compute-layer multi-tenancy risk distinct from VM escape, because no boundary is actually crossed; the leakage rides shared hardware. Mitigations include dedicated hosts and provider-side microarchitectural patching.

3 questions test this

Data remanence is the storage-layer leak; defeat it with encryption and cryptographic erase

Data remanence is residual data left on physical media after it is released, which a later tenant could recover if the provider reassigns that capacity without sanitizing it. Encrypting tenant data at rest makes leftover bytes useless without the key, and cryptographic erase (destroying the encryption key) renders all that data instantly unrecoverable, which scales far better than physically overwriting shared media. Both techniques are covered in NIST SP 800-88 on media sanitization.

Trap Insisting on physically overwriting media to handle remanence on shared cloud storage; you cannot reach the physical disks, so cryptographic erase by destroying the key is the cloud-appropriate control.

7 questions test this

Storage failures are usually exposure or missing encryption, not just remanence

Beyond remanence, the classic storage-layer failures are exposure and weak encryption: an object store left publicly readable, or a volume created without encryption at rest. These are configuration faults the customer typically owns, so the storage-layer answer to an exposed bucket is access policy plus encryption, not a control borrowed from another layer.

1 question tests this

A security analyst is evaluating access control mechanisms for an organization's cloud object storage containing sensitive financial…

The network layer is increasingly software-defined, so segmentation is configured not cabled

The network and communications layer carries tenant traffic between components and is increasingly software-defined, meaning segmentation, routing, and isolation are configured in software rather than wired into hardware. Its signature risks are east-west lateral movement, traffic interception, and missing segmentation, so the controls are network segmentation and traffic inspection. Because segmentation is a setting, a missing boundary is a misconfiguration, not a cabling gap.

1 question tests this

A security team is conducting a risk assessment for a multi-tier application deployed in an IaaS cloud environment. The application uses…

Compute is pooled CPU and memory allocated on demand

The compute layer is the provider's pooled CPU and memory that actually run workloads, allocated elastically on demand. Its multi-tenancy risks are resource exhaustion (one tenant's load starving others, which providers limit through quotas and scheduling) and side-channel leakage between workloads sharing a physical host. Compute is owned by the provider in every public-cloud service model.

1 question tests this

A cloud service provider discovers that a malicious tenant was able to read sensitive data from another tenant's virtual machine memory on…

The physical layer is the data-center facility itself

The physical environment is the data-center building, power, cooling, cabling, and physical access control beneath every other layer. Its concerns are physical breach, environmental failure, and safe disposal of failed media, and in public cloud the provider owns it entirely; the customer relies on attestation reports rather than inspecting the facility. Detailed facility design (site selection, HVAC, tiering) is the separate secure-data-center-design subtopic.

Shared responsibility shifts down the stack from IaaS to PaaS to SaaS

Moving to the cloud transfers the lower layers to the provider in a predictable order. Under IaaS the provider owns physical, network, and the virtualization host while the customer owns the guest OS and up. Under PaaS the provider also owns the OS and runtime, leaving the customer the application and data. Under SaaS the provider owns everything down to the application, leaving the customer only their data, access configuration, and identities. A stem naming a component plus a service model is asking for that intersection.

The customer never secures the hypervisor in public cloud

Across all public-cloud service models the provider owns the virtualization layer, so the customer cannot reach or harden the hypervisor; that responsibility is always the provider's. Guest-OS patching, by contrast, is the customer's job under IaaS but the provider's under PaaS and SaaS, where the provider owns the operating system. Any answer telling a public-cloud customer to harden the hypervisor is assigning provider-owned infrastructure to a party that cannot even access it.

Trap Assigning hypervisor hardening to the customer in public cloud; the customer has no access to the virtualization layer, so that is always the provider's responsibility.

Match the symptom to its layer, then take that layer's control

Domain 3.1 items usually describe a symptom and expect you to route it: residual files recovered by a new tenant means storage and data remanence, so encrypt with cryptographic erase; a guest running on the hypervisor host means virtualization, so harden and patch; leaked API keys snapshotting databases means the management plane, so MFA, least privilege, and logging. When two options both sound plausible, the one matching the layer the symptom lives in is correct; the distractor borrows a real control from the wrong layer.

Trap Picking a genuine control aimed at the wrong layer, such as a network firewall offered as the fix for a data-remanence problem; correct control follows the layer the symptom actually sits in.

Bare metal gives dedicated hardware with no hypervisor and the strongest isolation

Bare metal (dedicated-host) compute hands the customer a whole physical server with direct CPU and memory access and no virtualization layer, so there is no hypervisor to escape and no noisy neighbor. Choose it when a workload needs maximum tenant isolation, full OS control, hardware-level performance features, or licensing that forbids shared hosts.

Trap Reaching for a dedicated VM or single-tenant hypervisor when the requirement is no hypervisor at all; that still runs a virtualization layer.

5 questions test this

The noisy neighbor problem is one tenant's load degrading another's on shared hardware

In pooled multi-tenant infrastructure, one tenant consuming a disproportionate share of CPU, storage I/O, or network can degrade performance for other tenants on the same physical host. This is a performance and operational risk of resource sharing, not a breach of isolation; bare metal or dedicated capacity eliminates it.

2 questions test this

Micro-segmentation enforces policy per workload, not per subnet, to stop east-west lateral movement

Micro-segmentation places a virtual firewall at each workload's network interface (often via the SDN/NSG layer) so traffic is controlled host-by-host rather than at the subnet perimeter. Its purpose is to limit east-west (workload-to-workload) lateral movement inside a zone, a gap traditional perimeter segmentation leaves open. Zero Trust micro-segmentation keys rules to workload identity so only explicitly required flows are allowed.

Trap Treating subnet- or VLAN-level segmentation as equivalent; those control north-south perimeter traffic and still allow free lateral movement within a segment.

6 questions test this

East-west traffic flows between workloads inside the network; north-south crosses the perimeter

East-west traffic is internal flow between components such as web, app, and database tiers or microservices within the same virtual network. North-south traffic enters or leaves the network through the perimeter. Perimeter firewalls inspect north-south; micro-segmentation and distributed virtual firewalls are needed to inspect east-west.

8 questions test this

Tag- or identity-based segmentation lets policies follow workloads as they move or scale

Tag-based (identity-based) segmentation attaches security policy to a workload's labels or identity rather than its IP address, so rules automatically follow a VM as it migrates, scales, or changes IP. This avoids the continuous policy resynchronization that IP- and VLAN-based rules require whenever workload network locations change.

4 questions test this

Network security groups should be deny-by-default with explicit allow rules only

Network security groups (NSGs) provide stateful 5-tuple filtering (source/destination IP, source/destination port, protocol) at the virtual-switch level. Configure them deny-by-default and add explicit allow rules only for required flows; by default, subnets within one virtual network can talk freely, so isolation must be configured, not assumed.

Trap Assuming subnets in the same VNet are isolated by default; intra-VNet communication is permitted until an NSG denies it.

7 questions test this

VLANs cap at ~4,094 segments (12-bit ID); VXLAN's 24-bit VNI scales to ~16 million

The 802.1Q VLAN ID is 12 bits, limiting a network to about 4,094 usable VLANs, which is too few for large multi-tenant clouds. VXLAN overlay networking uses a 24-bit segment ID (VNI) supporting roughly 16 million logical segments and decouples the logical network from the physical fabric by encapsulating Layer 2 frames in UDP.

6 questions test this

SDN centralizes control in the controller, which becomes the single point of compromise

Software-defined networking separates the control plane from the data plane and centralizes decision-making in the SDN controller. That centralization simplifies and standardizes policy but makes the controller a single point of failure and the highest-value target: compromising it lets an attacker rewrite flow rules across the whole network. Controller-to-switch traffic is also exposed to man-in-the-middle flow-rule tampering if unencrypted.

Trap Picking a data-plane switch as the critical asset; the control-plane controller is the component that must be hardened first.

6 questions test this

Manage the SDN controller only from PAWs on a segmented out-of-band network

NSA guidance is to physically segment SDN controller management interfaces from the data interfaces and administer the controller exclusively from privileged access workstations (PAWs) connected to a dedicated out-of-band management (OOBM) network. This isolates administrative access so it cannot be reached through the production data path.

3 questions test this

Object, block, and file storage differ by access model: object = metadata + ID + API

Object storage holds data as objects, each with the payload, a unique identifier, and rich customizable metadata, accessed over HTTP/HTTPS REST APIs in a flat namespace; it suits unstructured data at petabyte scale. Block storage exposes raw fixed-size blocks for low-latency, high-IOPS workloads like databases and VM volumes. File storage offers a hierarchical NFS/SMB share for concurrent multi-user access with file-level permissions.

Trap Choosing object storage for a database needing high IOPS, or block storage for shared concurrent file access; match the access pattern to the type.

8 questions test this

Persistent block volumes survive VM stop or failure; ephemeral storage is lost on stop

Persistent block storage is network-attached and lives independently of the instance, so data survives a VM stop, restart, termination, or host failure and the volume can be reattached. Ephemeral (instance/local SSD) storage is physically tied to the host and is wiped permanently when the VM stops, terminates, or the host fails; use it only for caches and scratch data.

5 questions test this

Object storage reaches 11 nines durability via erasure coding across multiple AZs

Cloud object storage achieves extreme durability (e.g. 99.999999999%, '11 nines') by erasure-coding objects into data and parity fragments spread across many devices in multiple availability zones, plus redundant metadata and regular checksum validation. Durability protects against hardware failure and corruption only.

Trap Assuming high durability also protects against malicious or accidental deletion; a compromised account's delete is a valid operation, so versioning, MFA-delete, and immutable backups are still required.

5 questions test this

For VM-grade container isolation, run each container in a lightweight micro-VM (e.g. Kata)

Standard containers share the host kernel, a weaker boundary than a VM. When untrusted workloads need hardware-level isolation while keeping container tooling, use sandboxed runtimes like Kata Containers or Hyper-V isolation that run each container inside a stripped-down, OCI-compliant lightweight VM with its own guest kernel.

2 questions test this

KMS key rotation makes a new version for new encryption but keeps old versions for decryption

Automatic key rotation creates a new key version used for all new encryption, while the KMS retains previous versions to decrypt data already written under them. Existing ciphertext is not re-encrypted automatically, so rotation is transparent and requires no application change or bulk re-encryption.

Trap Assuming rotation re-encrypts existing data with the new key; old data stays under its original version until rewritten.

2 questions test this

Also tested in

CC Certified in Cybersecurity

The six component layers of a cloud platform

Compute, virtualization, and storage: pooling makes isolation the control

Compute and virtualization

Storage

Why the management plane is the apex target

Exam-pattern recognition for component layers

Reflex one: name the layer, then the control

Reflex two: map the component to its owner by service model

Distractor patterns to expect

The six cloud component layers: what each is and its signature concern

Decision tree

Cheat sheet

Also tested in

References