11.1 Build Physical & Logical Infrastructure (Domain 5.1)
Key Takeaways
- Domain 5 is 17% of the August 2026 CCSP exam; Domain 5.1 focuses on building and implementing physical and logical infrastructure securely—hardware roots of trust, secure defaults, management-plane tooling, virtual hardware, and guest OS toolsets.
- Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs) provide cryptographic roots of trust: HSMs protect keys and crypto operations at high assurance; TPMs support measured/secure boot and device-bound secrets on hosts.
- Secure-by-default means production-ready baselines at install time: least privilege, closed ports, encrypted management channels, and approved images—not open defaults that operators must remember to harden later.
- Type-1 hypervisors run on bare metal for production multi-tenant isolation; Type-2 hypervisors run on a host OS and are more common for labs and endpoints—know the isolation and trust-boundary differences.
- Management-plane tools (orchestrators, consoles, schedulers) are high-value attack surfaces; install and configure them with MFA, network isolation, least privilege, and audit logging before placing workloads.
Build Physical & Logical Infrastructure
Domain 5 — Cloud Security Operations — carries 17% of the August 2026 CCSP exam. It is where design becomes runtime reality: how cloud platforms are built, operated, and governed day to day. Domain 5.1 is the construction phase: build and implement physical and logical infrastructure for the cloud environment. The outline groups hardware-specific security (HSM, TPM), secure by default, management-plane tooling, virtual hardware configuration (network, storage, memory, CPU, hypervisor types), and guest OS virtualization toolsets.
If earlier domains asked what components exist and how data and apps should be protected, 5.1 asks: how do you stand up the platform securely so operations (5.2) and control frameworks (5.3) have something trustworthy to run on?
Why “Build” Is a Security Domain
Infrastructure built with open management APIs, untrusted boot chains, or flat virtual networks cannot be “patched into security” later without expensive redesign. Build-time decisions lock in attack surface for years:
| Build decision | If done poorly | If done well |
|---|---|---|
| Key custody | Soft keys on general VMs; theft = crypto compromise | HSM/KMS with access policy and audit |
| Boot integrity | Rootkits survive reboots | TPM-backed measured/secure boot |
| Defaults | Admin ports open; weak passwords | Secure-by-default images and templates |
| Hypervisor choice | Nested/lab-grade isolation for multi-tenant production | Type-1 with hardened management |
| Management plane | Internet-exposed console with shared accounts | Isolated plane, MFA, named identities |
| Guest toolsets | Unmanaged agents with excess privilege | Controlled, signed, least-privilege tools |
Shared responsibility reminder: In public multi-tenant cloud, the CSP typically builds and hardens the physical facility, fabric, and Type-1 hypervisor. Customers build logical infrastructure inside the tenancy (VPCs, VMs, images, KMS usage, management of their own private cloud or hybrid edge). On private cloud or IaaS-plus-ops models, more of 5.1 falls on the customer. Exam stems signal ownership with phrases like “private cloud,” “colocation,” “customer-managed hypervisor,” or “CSP-managed region.”
Hardware-Specific Security: HSM and TPM
Hardware Security Module (HSM)
An HSM is specialized hardware designed to generate, store, and use cryptographic keys with strong physical and logical protections. Keys preferably never leave the HSM in plaintext. Operations (sign, decrypt, unwrap) occur inside the module under authenticated, authorized sessions.
| HSM attribute | Why CCSP cares |
|---|---|
| Tamper resistance / evidence | Physical attack raises alerts or zeroizes keys |
| Role separation | Crypto officer vs user roles; dual control for sensitive ops |
| FIPS / Common Criteria alignment | Procurement and compliance evidence (know the idea, not product catalogs) |
| Key lifecycle | Generate, backup (encrypted key ceremony), rotate, destroy |
| Cloud form | Dedicated HSM appliances, cloud HSM services, or KMS backed by HSMs |
Use cases: root and intermediate CA private keys, payment or high-value application keys, disk encryption master keys when policy demands hardware-backed custody, code-signing keys for production pipelines.
Exam discrimination: Encrypting a volume with a software key stored as a file next to the data is not equivalent to HSM-backed key custody. Using a cloud KMS that is itself HSM-backed can meet many requirements if access policy, logging, and customer key control match risk appetite.
Trusted Platform Module (TPM)
A TPM is a hardware (or firmware) root of trust on a host that stores measurements, supports sealed storage, and enables secure boot / measured boot workflows. Unlike an HSM focused on enterprise key services, a TPM is typically platform-bound to a server, workstation, or appliance.
| TPM capability | Operational value |
|---|---|
| Platform Configuration Registers (PCRs) | Record hashes of boot components |
| Sealed keys | Keys decrypt only if PCR state matches expected good boot |
| Attestation | Prove to a remote party that the host booted a known-good stack |
| Device identity | Bind credentials to hardware rather than only software secrets |
Cloud relevance: Bare-metal and confidential-computing offerings often expose TPM or equivalent roots of trust so customers can verify host integrity before placing sensitive workloads. Private-cloud operators should require TPM-backed disk encryption and secure boot on hypervisors and management hosts where supported.
HSM vs TPM (Quick Contrast)
| Dimension | HSM | TPM |
|---|---|---|
| Primary mission | Protect enterprise crypto keys and ops | Protect platform integrity and local secrets |
| Typical scale | Shared service / appliance / cloud service | Per-host root of trust |
| Classic use | PKI, application keys, KMS backend | Secure boot, BitLocker/LUKS sealing, attestation |
| Exam trap | Calling any encrypted disk “HSM” | Treating TPM as a multi-tenant key vault for all apps |
Secure by Default
Secure by default means that when infrastructure or software is installed or provisioned, the initial state is restrictive and safe, not open for convenience. Operators should need deliberate action to widen access, not to close it.
| Secure-by-default practice | Anti-pattern |
|---|---|
| Management interfaces bound to private networks | SSH/RDP open to 0.0.0.0/0 on first boot |
| Unique credentials or forced rotation on first login | Shared vendor default passwords left in place |
| Unnecessary services disabled in golden images | Full desktop stack and debug ports on production images |
| Encryption and logging enabled in templates | “Turn on encryption later” never completed |
| Least-privilege roles in IaC modules | Admin-equivalent default service accounts |
| Private endpoints preferred for data services | Public endpoints as the template default |
Implementing Secure Defaults in Cloud Build
- Golden images and hardened baselines — CIS-aligned or organization-approved images for hosts and containers; rebuild rather than perpetual snowflake patching where possible.
- Infrastructure as Code defaults — modules that create private subnets, deny-by-default security groups, encryption flags, and logging sinks unless explicitly overridden through a controlled process.
- Organization policies / guardrails — prevent creation of public storage, unrestricted ingress, or disabled logging at the account/subscription level.
- Management plane defaults — MFA required, session timeouts, API logging on, break-glass documented but rare.
- Supply chain for build — signed images, trusted registries, verified hypervisor and firmware updates.
Exam tip: When a stem describes a breach from a “freshly provisioned” system with defaults left open, the missing principle is often secure by default (or failure to enforce it with guardrails), not merely “more antivirus.”
Installation and Configuration of Management Plane Tools
The management plane is the set of interfaces and services used to create, configure, schedule, orchestrate, and monitor infrastructure and workloads—cloud consoles, APIs, orchestrators (for example, Kubernetes control planes), configuration managers, and virtualization managers. Compromising the management plane often yields control of all data-plane assets.
| Build/configure control | Rationale |
|---|---|
| Network isolation | Management subnets/VLANs/VPCs separate from general user traffic; no direct internet admin where avoidable |
| Strong authentication | MFA, phishing-resistant factors for admins; federated SSO with conditional access |
| Authorization | Role-based access; separate platform admin from workload deploy roles |
| API protection | TLS only, rate limiting, IP allowlisting or private connectivity, key/credential hygiene |
| Audit logging | Immutable or append-only trails for all privileged actions; alerts on logging disable |
| Patch and version control | Orchestrators and managers stay current; known CVEs on control planes are critical |
| High availability | HA control planes so security operations and recovery do not depend on a single manager node |
| Secrets for automation | Pipelines use short-lived credentials; no long-lived god keys in CI logs |
Installation sequence mindset (vendor-neutral): harden the host or control-plane nodes first → install management software from trusted sources → configure authN/authZ and logging before connecting production clusters → enroll compute nodes with mutual authentication → only then onboard workloads. Building workloads first and “adding a manager later” often leaves orphan nodes with ad-hoc SSH and no central policy.
Worked scenario: A team stands up a private cloud. They install the virtualization manager on a general-purpose VLAN with default admin password “admin,” enable remote console from the internet “for convenience,” and only later attach production databases. An attacker brute-forces the console and snapshots every VM. The root failure is management-plane build and configuration, not a missing WAF on an application.
Virtual Hardware Specific Security Configuration
Cloud and virtualization present virtual hardware—logical CPU, memory, storage, and network devices mediated by a hypervisor or cloud fabric. Domain 5.1 expects configuration requirements across these dimensions and explicit knowledge of Type-1 vs Type-2 hypervisors.
Hypervisor Types
| Type | Model | Typical use | Security notes |
|---|---|---|---|
| Type-1 (bare metal) | Hypervisor runs on hardware; guests above it | Production cloud, enterprise virtualization | Smaller trusted computing base relative to full general-purpose host OS; still requires patching, management isolation, and firm firmware hygiene |
| Type-2 (hosted) | Hypervisor runs as software on a host OS | Labs, developer desktops, some nested scenarios | Trust includes the host OS; escape may compromise host and other VMs; rarely appropriate as multi-tenant production fabric |
Exam framing: Production multi-tenant isolation assumptions map to Type-1. Nested virtualization and Type-2 on endpoints introduce additional layers and risks that must be justified.
Network (Virtual)
| Configuration theme | Secure practice |
|---|---|
| Segmentation | Separate tenant, environment (prod/non-prod), and management networks |
| Virtual switches / overlays | Prevent promiscuous mode and MAC spoofing where policy requires; control trunking |
| Security groups / microsegmentation | Default deny; allow only required flows |
| No shared NICs across trust zones without controls | Avoid accidental bridging of sensitive VLANs |
Storage (Virtual)
| Theme | Practice |
|---|---|
| Isolation | LUNs/volumes mapped only to authorized hosts; multipathing without cross-tenant exposure |
| Encryption | Encrypt sensitive virtual disks; protect key access |
| Snapshots | Treat snapshots as sensitive clones; restrict who can create/export |
| Thin provisioning risks | Monitor capacity; noisy-neighbor and out-of-space denial scenarios |
Memory and CPU
| Theme | Practice |
|---|---|
| Memory isolation | Hypervisor enforces separation; beware of speculative-execution classes historically requiring patches and sometimes site-isolation features |
| Memory overcommit | Understand performance and side-channel tradeoffs; sensitive workloads may require reservations or dedicated hosts |
| CPU scheduling | Resource pools and limits prevent noisy neighbors from starving security/monitoring agents |
| Device passthrough | PCI passthrough / GPU assignment reduces hypervisor mediation—use only with clear isolation requirements |
| Confidential computing (awareness) | Memory encryption / enclaves where threat model includes privileged host admins |
Hypervisor Hardening Checklist (Build-Time)
- Minimal management services on hypervisor hosts.
- Separate management interfaces; disable unused physical NICs and services.
- Signed updates; controlled change for firmware and hypervisor patches.
- Time sync, logging to SIEM, file integrity where applicable.
- Role-based access to virtualization APIs; no shared root for daily ops.
- Disable or strictly control features that weaken isolation (unnecessary device sharing, unrestricted console).
Installation of Guest OS Virtualization Toolsets
Guest OS virtualization toolsets (paravirtual drivers, guest agents, integration services) improve performance and enable host–guest cooperation: graceful shutdown, time sync, heartbeat, clipboard/file features, and disk/network drivers. They also expand the attack surface between host and guest.
| Toolset aspect | Security consideration |
|---|---|
| Source authenticity | Install only vendor-signed packages matching the hypervisor version |
| Least function | Disable unused integration features (shared folders, clipboard) on sensitive guests |
| Privilege | Agents often run with high privilege—monitor and patch them |
| Version skew | Mismatched tools cause instability and may miss security fixes |
| Inventory | Know which VMs have agents; orphan agents after migrations are risk |
Build practice: Bake approved toolset versions into golden images; update through the same patch pipeline as the guest OS; document which features are allowed in production vs developer VMs.
Putting Domain 5.1 Together for the Exam
- Identify whether the stem is about hardware root of trust (HSM/TPM), defaults, management plane, virtual hardware/hypervisor, or guest tools.
- Map Type-1 vs Type-2 to production isolation expectations.
- Prefer answers that secure the management plane first, then data plane.
- Remember public cloud: customers configure logical infrastructure and consume provider HSMs/TPMs as offered; they do not rack the provider’s hypervisors.
Common Traps
- Equating any encryption with HSM-backed key custody.
- Using Type-2 mental models for multi-tenant production isolation.
- Leaving management tools on default credentials “until go-live.”
- Enabling every guest integration feature for convenience on regulated systems.
- Ignoring secure-by-default because “we will harden after install.”
A private-cloud team needs hardware-backed protection for offline CA private keys with dual-control key ceremonies and tamper-evident storage. Which technology best matches this requirement?
Which statement correctly contrasts Type-1 and Type-2 hypervisors for CCSP Domain 5.1?
A new virtualization manager is installed with default admin credentials and is reachable from the general corporate network before any production VMs are migrated. What Domain 5.1 principle is most clearly violated?
How do TPM and HSM roles typically differ when building cloud or virtualization hosts?