7.1 Cloud Infrastructure Components (Domain 3.1)

Certified Cloud Security Professional CCSP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance

2 Domain 1: Cloud Concepts & Architecture Foundations

2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)

3 Domain 1: Secure Design, CSP Evaluation & AI/ML

3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)

4 Domain 2: Data Concepts, Storage & Protection Technologies

4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)

5 Domain 2: Discovery, Classification & Information Rights Management

5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)

6 Domain 2: Retention, Auditability & AI/ML Data Protection

6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)

7 Domain 3: Infrastructure Components, Data Center & Risks

7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)

8 Domain 3: Security Controls & Business Continuity / Disaster Recovery

8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)

9 Domain 4: Application Security Awareness & Secure SDLC

9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)

10 Domain 4: Software Assurance, Architecture & IAM

10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)

11 Domain 5: Build, Operate & Operational Controls

11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)

12 Domain 5: Forensics, Stakeholder Communication & Security Operations

12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)

13 Domain 6: Legal Requirements, Privacy & Audit

13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)

14 Domain 6: Enterprise Risk Management & Cloud Contracts

14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)

7.1 Cloud Infrastructure Components (Domain 3.1)

Key Takeaways Explain This Topic AI

Cloud infrastructure comprises physical environment, network and communications, compute, virtualization, storage, and the management plane — secure each layer under shared responsibility.

The management plane (APIs, consoles, orchestration) is the highest-value control surface: compromise there can reconfigure the entire estate.

Virtualization (hypervisors, containers, multi-tenancy isolation) underpins density and elasticity but introduces escape, sprawl, and noisy-neighbor risks.

Physical and environmental protections remain relevant even when customers never enter the facility — region, zone, and facility design still affect availability and compliance.

On CCSP scenarios, identify which infrastructure component holds the asset and who operates it before assigning controls.

Last updated: July 2026

Cloud Infrastructure Components

Domain 3 — Cloud Platform and Infrastructure Security — carries 17% of the August 2026 CCSP exam weight. Domain 3.1 asks you to comprehend cloud infrastructure components : the physical environment, network and communications, compute, virtualization, storage, and the management plane. This is not a product catalog. The exam expects you to map a workload to the components that host it, decide what the CSP owns versus what the customer configures, and spot weak layers in multi-tenant designs.

Infrastructure is the substrate for Domains 1–2 concepts. Service categories (IaaS/PaaS/SaaS) sit on these components. Data at rest and in transit lives on storage and network fabric. When a stem describes a regional outage, a hypervisor flaw, or a stolen API key, Domain 3.1 vocabulary tells you which component failed and how far the blast radius extends .

Why Component Thinking Matters

Traditional data-center security often treated “servers and firewalls” as a single blob. Cloud decomposes the stack into programmable layers:

Physical environment — buildings, power, cooling, cabling, physical access.

Network and communications — fabric, SDN, edge, interconnects, DNS/TLS paths.

Compute — CPUs, memory, GPUs, bare metal, instances, functions.

Virtualization — hypervisors, containers, isolation boundaries.

Storage — block, object, file, local/ephemeral media and the storage network.

Management plane — APIs, consoles, identity for infrastructure, orchestration, billing/metering hooks.

A control that works at one layer can be irrelevant at another. Hardening a guest OS does nothing if the management plane allows an attacker to detach volumes or open security groups. CCSP rewards candidates who secure all six , with special emphasis on the management plane.

Component Primary function High-value security questions

Physical environment Host hardware safely Who enters the facility? Power/HVAC redundancy? Geographic risk?

Network & communications Connect workloads and users Segmentation? Encryption in transit? Path diversity?

Compute Execute workloads Patch/image integrity? Side channels? Capacity limits?

Virtualization Share hardware with isolation Hypervisor type? Escape risk? Tenant separation?

Storage Persist data Encryption? Access policies? Durability and sanitization?

Management plane Create, change, destroy everything Strong identity? Least privilege? Logging? Break-glass?

Physical Environment

The physical environment is the facility and site context: location, structure, power delivery, cooling plant, fire suppression, physical access control, cabling pathways, and supporting systems (generators, UPS, fuel, water). In public cloud, customers rarely tour these spaces, but they still depend on them . Availability SLAs, multi-AZ designs, and compliance attestations (SOC 2, ISO/IEC 27001, sector addenda) are how customers gain assurance without owning the building.

What “physical” includes in cloud discussions

Element Why it matters to cloud security
Site selection Flood, seismic, political, and connectivity risk; distance for latency and DR
Physical access Mantraps, badges, biometrics, visitor escort, CCTV, dual control for cages
Power Utility feeds, UPS, generators, PDU diversity — supports design resilience (3.2)
Cooling HVAC capacity and redundancy prevent thermal shutdowns
Fire detection/suppression Protects media and people without destroying equipment unnecessarily
Cable plant Fiber/copper pathways; multi-vendor diverse entry for connectivity resilience
Media handling Drive destruction, secure decommission, chain of custody for failed disks

Shared responsibility: CSP owns physical security of provider facilities for public/private hosted clouds. Customers own physical security for on-premises private cloud and customer-managed edge/colo equipment. Hybrid designs split both — map each asset to a facility owner.

Exam trap: Assuming “we use the cloud, so physical security is irrelevant.” Physical compromise of a provider site is rare relative to API misconfiguration, but availability and compliance still rest on physical design . Another trap: treating all “regions” as identical — climate, power grid stability, and legal jurisdiction differ.

Worked scenario: A company places both primary and DR in the same metro campus “for low latency.” A flood or regional grid event can take both “redundant” sites offline. Physical environment analysis would have forced geographic separation or a second region — even though every virtual machine looked “highly available” inside one metro.

Network and Communications

Network and communications deliver connectivity among users, workloads, storage, partner networks, and the internet. In cloud, much of this is software-defined : virtual networks, subnets, route tables, gateways, load balancers, private service endpoints, and policy-driven security groups replace or augment hardware ACLs.

Building blocks

Construct Role Security focus
Virtual networks / VPCs Tenant-isolated address spaces CIDR planning, peering trust, default deny
Subnets & route tables Segmentation and path control Public vs private placement; forced tunneling
Security groups / NSGs Stateful host/ENI-level filters Least ports; no 0.0.0.0/0 on admin
Network ACLs Stateless subnet filters Defense in depth; egress control
Load balancers / ingress North-south traffic distribution TLS termination, WAF attachment, health checks
VPN / Direct Connect-style private links Hybrid connectivity Keying, routing leaks, dual paths
DNS Name resolution DNSSEC where applicable; phishing/subdomain risk
CDN / edge Performance and absorption Cache poisoning/purge, origin protection
Service meshes / east-west Microservice identity and mTLS Sidecar policy, certificate lifecycle
Communications security principles for CCSP

Encrypt in transit by default (TLS for APIs and user sessions; private links for hybrid).

Segment by trust — production vs non-production, tenant vs shared services, management vs data planes.

Constrain egress — prevent exfiltration and SSRF-driven metadata access where possible.

Protect the edge — DDoS absorption, rate limiting, geo controls when justified.

Log flow metadata — flow logs and DNS logs support detection and forensics.

Multi-tenancy implication: Tenants share physical switches and often shared edge capacity. Logical isolation (overlays, VRFs, hypervisor vSwitches, security groups) must hold. Side-channel and noisy-neighbor risks are real but exam scenarios more often fail on mis-peering, overly broad NSGs, and public admin endpoints .

Exam tip: Distinguish data plane traffic (application payloads) from control/management plane traffic (API calls that reconfigure infrastructure). Compromising communications to the management plane is more severe than sniffing a single app flow.

Compute

Compute is the execution capacity: CPUs, memory, accelerators (GPUs/TPUs), bare-metal hosts, virtual machines, containers-as-a-service nodes, and serverless function runtimes. Compute consumes network and storage and is scheduled by virtualization/orchestration layers.

Compute forms

Form Description Typical customer control surface
Bare metal Dedicated physical server Full stack from firmware/OS up
Virtual machine Guest OS on hypervisor OS, agents, apps; image choice
Container host / node Shared kernel model for pods Node OS (if IaaS), runtime config, workloads
Serverless / functions Event-driven ephemeral execution Code, config, IAM, dependencies
Managed instance groups / ASGs Autoscaled fleets Templates, scaling policies, health
Security themes for compute

Theme Why it matters
Image integrity Golden images, minimal base, signed provenance, no secrets baked in
Hardening & patching CIS-style baselines; rapid patch of exposed services
Identity of the workload Instance/service roles instead of long-lived keys on disk
Resource limits Quotas prevent runaway cost and some DoS amplification
Confidential computing (optional) TEEs protect data-in-use for high-sensitivity processing
Side channels Speculative execution, cache timing in dense multi-tenant hosts
Ephemeral residue Local disks and memory may hold secrets after crash

Shared responsibility shifts sharply by form: bare metal and classic IaaS VMs leave more OS duty with the customer; serverless shifts OS patching to the CSP while customers retain code and IAM risk. CCSP stems often hide the form — “functions process PII” implies compute that is ephemeral, API-triggered, and IAM-centric rather than “patch the guest weekly” as the primary answer.

Autoscaling is a double-edged sword: it supports availability under load but can amplify compromised automation (Domain 1 elasticity) and expand the set of nodes an attacker can land on once an image or pipeline is poisoned.

Virtualization

Virtualization abstracts physical hardware so multiple logical systems share CPUs, memory, and devices. It is the engine of multi-tenancy, rapid provisioning, snapshots, and live migration.

Hypervisors and isolation

Type Model Notes for exam

Type 1 (bare-metal) Hypervisor runs on hardware Common in cloud provider hosts; smaller TCB relative to hosted Type 2

Type 2 (hosted) Hypervisor on a general-purpose host OS More common on workstations; larger attack surface via host OS

Container runtime OS-level isolation (namespaces, cgroups) Higher density; shared kernel risk; not a full VM boundary

MicroVMs / lightweight VMs Stronger isolation with fast start Used for multi-tenant functions/sandboxes
Virtualization security concerns

Hypervisor escape — guest breaks into host or sibling guests (rare but catastrophic).

VM sprawl — untracked instances increase patch and inventory debt.

Insecure snapshots/templates — secrets and vulnerabilities cloned at scale.

Weak isolation config — shared folders, overly permissive device passthrough, nested virtualization without need.

Live migration exposure — memory contents in transit on the fabric if not protected.

Container breakout — privileged pods, hostPath mounts, vulnerable runtimes.

Noisy neighbor — resource contention affecting availability (availability risk more than confidentiality).

Defense patterns: Keep hypervisors and host agents patched (CSP duty on public cloud); use minimal privileges for guests; separate sensitive tenants on dedicated hosts when risk justifies cost; enforce image signing; restrict nested virt and raw device mapping; apply pod security standards for containers.

Virtualization also enables security positives : rapid rebuild (immutable infrastructure), snapshot forensics (with chain-of-custody care), microsegmentation via virtual NICs, and test environments that mirror production without dual hardware investment.

Exam discrimination: If the question is about guest OS patching on IaaS, answer is often customer. If the question is about hypervisor patching on a public CSP, answer is CSP. If the question is about container escape on a managed Kubernetes service, split carefully: CSP secures control plane (when managed); customer secures cluster RBAC, workloads, and often node configuration depending on the offering.

Storage (Infrastructure View)

Domain 2 deep-dives data storage architectures for data security . Domain 3.1 treats storage as an infrastructure component : the media, controllers, storage networks, and services that present capacity to compute.

Infrastructure storage facets

Facet Description Security angle
Block volumes LUNs/virtual disks attached to compute Attach/snapshot permissions; encryption
Object stores API-addressable durable objects IAM/policies; public access; immutability
File shares NFS/SMB-style multi-mount Auth, export rules, ransomware
Local/ephemeral disks Instance-bound scratch Residue; no durability assumption
Storage fabric SAN/NAS/SDN paths to media Zoning, multipathing, encryption in transit
Replication engines Sync/async copies across AZ/region Residency; secondary access control

Infrastructure threats include unauthorized volume attach, fabric zoning mistakes, backup target wipeout, and failure of media sanitization on decommission. Customers must still configure access and encryption ; providers operate the underlying durable fabric for managed services.

Link forward: Domain 3.2 resilience design (power/HVAC/connectivity) keeps storage clusters online; Domain 3.3 risk analysis treats storage misconfiguration and multi-tenant residual risk as threat scenarios.

Management Plane

The management plane is the set of interfaces and control systems used to provision, configure, monitor, orchestrate, and decommission infrastructure and services. It includes public and private APIs, web consoles, CLIs, infrastructure-as-code runners, orchestration control planes, and often billing/organization hierarchy tools.

If the data plane moves packets and the control plane steers routing inside a device, the cloud management plane steers the entire cloud : create networks, spawn compute, open firewall rules, mint keys, delete logs. That is why management-plane compromise is frequently more severe than application compromise.

Management plane elements

Element Examples of function Priority controls

Identity for admins & automation Human users, service principals, federation MFA, conditional access, least privilege, JIT/PAM

APIs & consoles CRUD on every resource type Private endpoints where possible; IP allow lists; TLS

Orchestration / schedulers Cluster managers, autoscalers, IaC pipelines Signed templates; segregated deploy roles; approval gates

Organization / account structure Folders, accounts, subscriptions, landing zones Guardrails, SCPs/org policies, separation of prod

Logging & audit of management actions Cloud trail-style logs Immutable log archive; alert on policy changes
Secrets for infrastructure Bootstrap credentials, deploy keys Vaulting; short TTL; no long-lived keys in code
Why CCSP emphasizes this component

Breadth: One role with */* can expose every other component.

Speed: APIs reconfigure thousands of resources in minutes (elasticity).

Abstraction: Customers never touch physical consoles in public cloud — APIs are the console.

Shared tenancy of control systems: Provider multi-tenant control planes must isolate tenants rigorously; customers must isolate environments within their tenancy.

Hardening checklist (customer side): Enforce MFA on all privileged humans; prefer workload identity federation over static access keys; split duties (network admins ≠ data admins ≠ billing); deny risky actions at organization policy level (e.g., unrestricted public storage); continuous monitor for anomalous API calls; break-glass accounts offline and monitored; never run production changes from personal untrusted endpoints without session controls.

Provider side (assurance): Customers evaluate how the CSP protects its own management plane via certifications, penetration testing summaries, and architecture whitepapers — Domain 1.5 evaluation themes reappear here.

Integrating the Six Components

Trace a simple IaaS web app:

Physical environment — runs in two AZs in a chosen region (facility risk accepted via multi-AZ).

Network — private subnets for app tiers; public only for load balancer; strict NSGs.

Compute — autoscaled VMs from hardened images with instance roles.

Virtualization — CSP hypervisor isolation between tenants; customer avoids privileged containers on the same nodes as untrusted code.

Storage — encrypted volumes for app data; object store for static assets with block public access.

Management plane — IaC pipeline with least-privilege deploy role; all API calls logged to a write-once archive.

Fail any one layer and the design weakens. Fail the management plane and the other five can be undone programmatically.

Common Traps

Securing guest OS while leaving root-equivalent cloud IAM roles unrestricted.

Equating multi-AZ virtual redundancy with multi-region or multi-facility physical diversity.

Treating containers as equivalent isolation to Type 1 hypervisors in every threat model.

Ignoring storage fabric and snapshot permissions when reviewing “disk encryption only.”

Assuming serverless has no infrastructure risk — IAM, dependencies, and cold-start data residue remain.