7.1 Cloud Infrastructure Components (Domain 3.1)

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:

1. Physical environment — buildings, power, cooling, cabling, physical access.
2. Network and communications — fabric, SDN, edge, interconnects, DNS/TLS paths.
3. Compute — CPUs, memory, GPUs, bare metal, instances, functions.
4. Virtualization — hypervisors, containers, isolation boundaries.
5. Storage — block, object, file, local/ephemeral media and the storage network.
6. 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.

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

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

Communications security principles for CCSP

1. Encrypt in transit by default (TLS for APIs and user sessions; private links for hybrid).
2. Segment by trust — production vs non-production, tenant vs shared services, management vs data planes.
3. Constrain egress — prevent exfiltration and SSRF-driven metadata access where possible.
4. Protect the edge — DDoS absorption, rate limiting, geo controls when justified.
5. 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

Security themes for compute

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

Virtualization security concerns

1. Hypervisor escape — guest breaks into host or sibling guests (rare but catastrophic).
2. VM sprawl — untracked instances increase patch and inventory debt.
3. Insecure snapshots/templates — secrets and vulnerabilities cloned at scale.
4. Weak isolation config — shared folders, overly permissive device passthrough, nested virtualization without need.
5. Live migration exposure — memory contents in transit on the fabric if not protected.
6. Container breakout — privileged pods, hostPath mounts, vulnerable runtimes.
7. 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

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

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:

1. Physical environment — runs in two AZs in a chosen region (facility risk accepted via multi-AZ).
2. Network — private subnets for app tiers; public only for load balancer; strict NSGs.
3. Compute — autoscaled VMs from hardened images with instance roles.
4. Virtualization — CSP hypervisor isolation between tenants; customer avoids privileged containers on the same nodes as untrusted code.
5. Storage — encrypted volumes for app data; object store for static assets with block public access.
6. 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.