Cloud Security Architecture and Shared Responsibility
Domain 7: Cloud Security Architecture and Shared Responsibility
This domain tests how you place controls across provider and customer boundaries and design resilient, low-blast-radius architectures. Expect shared responsibility variations by service model, landing zones, and trust boundaries.
Core rules
- The provider is responsible for security of the cloud; the customer is responsible for security in the cloud. The split moves with the service model: IaaS leaves OS and runtime to the customer; PaaS moves patching to the provider but leaves identity, configuration, and data to the customer; SaaS leaves most operational controls to the provider but never data classification or user access.
- Separate control plane and data plane. A compromised control plane can reconfigure or delete resources; protect it with strong identity, MFA, and approval workflows.
- Use a landing zone with accounts/subscriptions/projects segmented by environment, business unit, and sensitivity. Centralize identity, logging, networking, and guardrails.
- Design for least privilege and blast radius: separate production from nonproduction, use dedicated accounts for sensitive data, and avoid shared admin roles.
Worked example
A team uses a managed relational database. The provider patches the engine and secures the physical host. The customer must still configure private networking, IAM database authentication, encryption with customer keys, backup retention, and audit logging. Reasoning: the provider's patching does not fix a public endpoint or an overprivileged application account. The exam often asks which tasks remain with the customer for a managed service; answer configuration, identity, data, and access, not hypervisor patching.
Traps
- Assuming a managed service removes all customer responsibility.
- Confusing 'security of the cloud' with 'security in the cloud.'
- Forgetting that identity and access management is always a customer responsibility.
- Treating network segmentation as sufficient without workload identity controls.
- Building one flat production account because it is simpler.