Cloud and Virtualization Security Architecture
This domain tests how responsibility shifts across IaaS, PaaS, and SaaS, how landing zones enforce guardrails, and where virtualisation and container layers introduce new attack surface. Expect questions on scope reduction, organisational policy, and workload identity.
Shared responsibility
In IaaS the provider secures facilities, hardware, and hypervisor; the customer secures the OS, runtime, applications, data, identity, and configuration. PaaS shifts the runtime to the provider. SaaS shifts almost everything except data classification, identity, configuration, and usage. The customer always retains identity, data, and configuration ownership. Inherit provider attestations (ISO 27001, SOC 2) rather than re-auditing the provider.
Landing zone and guardrails
Separate accounts or subscriptions by environment and data sensitivity; centralise logging and security tooling in dedicated accounts the workload cannot write to. Apply organisation policies, SCPs, Azure Policy, and GCP Org Policy. Preventive guardrails (deny) beat detective guardrails (alert). An account-vending pipeline makes secure configuration the default. Network: hub-and-spoke, private endpoints, no public storage.
Virtualisation
Hypervisor attack surface includes VM escape, hyperjacking, snapshot and image sprawl, resource pooling, and management-plane compromise. Harden templates, patch, restrict console access, encrypt snapshots.
Containers and serverless
Kubernetes: RBAC, admission control, network policy, pod security standards, image signing and SBOM, registry scanning, secrets externalised rather than baked into images or environment variables. Serverless: per-function IAM roles, event payload validation against injection, dependency risk, logging on cold start.
Worked example
A startup runs a payment workload in AWS. Reasoning: isolate the cardholder environment into its own account so scope is defined by the account boundary plus the network path; an SCP denies public S3 and unapproved regions; CloudTrail ships to a logging account the workload cannot modify; KMS keys are per environment; workloads sit in private subnets behind a WAF. Scope reduction is the point - the auditor then evaluates one account instead of the whole estate.
Traps
- "The provider patches everything" in IaaS.
- Assuming SaaS means no customer controls.
- Over-broad instance roles.
- Secrets stored in images or environment variables.
- Missing control-plane logging.
- Public snapshots and buckets.
- Ignoring egress from cloud workloads.