Cloud Architecture and Shared Responsibility
This domain tests where the provider's responsibility ends and yours begins across IaaS, PaaS, and SaaS, and how that boundary changes secure design. Expect questions on service models, deployment models, inherited controls, and reference architectures.
Core rules
- The provider is always responsible for physical security, the hypervisor, and the managed service's underlying infrastructure. You are always responsible for data, identities, access policy, and configuration.
- IaaS: you patch the guest OS, middleware, and applications. PaaS: you secure code, data, identities, and service configuration; the provider patches the runtime and OS. SaaS: you manage users, data sharing, and SaaS security settings.
- Shared controls such as patching strategy, logging, and incident response require explicit interfaces and evidence.
- Design for failure and least privilege: separate accounts or subscriptions, private networking, and centralized identity.
Worked example
A team runs a VM, a managed PostgreSQL service, and a SaaS CRM. For the VM, they own OS patching, host firewall, and disk-encryption configuration. For PostgreSQL, the provider patches the engine and host, but the team owns database roles, network access, encryption key policy, and backup retention. For the CRM, the team owns SSO, MFA, role assignments, and data-export controls. Reasoning: the service model shifts the patch line, not the data and identity line.
Traps
- Quoting "the provider secures the cloud, you secure what is in it" without applying it to the specific service.
- Assuming PaaS removes the need for database access reviews.
- Ignoring SaaS-to-SaaS OAuth grants and over-shared files.