Cloud Architecture and Design
What this domain tests
The Cloud Architecture and Design domain checks whether you can look at a cloud solution and identify where controls actually live. Expect questions on the NIST SP 800-145 service models (IaaS, PaaS, SaaS), deployment models (public, private, community, hybrid), the shared responsibility model, and design choices that affect security and auditability: tenancy, network segmentation, identity and access management, encryption and key management, logging, APIs, portability and interoperability.
Core rules
- Responsibility moves with the service model. In IaaS the customer owns the guest OS and above; in PaaS the provider owns the runtime; in SaaS the provider owns the application, but the customer still owns identity lifecycle, data classification, configuration and user behavior.
- The shared responsibility model is not a transfer of all risk. The provider secures the cloud; the customer secures what it puts in the cloud and how it configures it.
- Design for evidence: centralized logging, immutable audit trails, API-level configuration visibility and clear data flows make later assurance cheaper.
- Multi-tenancy, resource pooling and elasticity change the threat model. Isolation, encryption, key custody and network controls become primary.
Worked example
A company buys SaaS payroll. The vendor states it is ISO/IEC 27001 certified. The auditor asks who owns access review. Reasoning: certification covers the provider's management system, not the customer's users. The customer owns joiner-mover-leaver provisioning, role design, MFA enforcement and periodic access review; the provider owns application infrastructure, patching and platform logging. Evidence must combine the provider's attestation and the customer's IAM logs.
Traps
Assuming the provider is responsible for all controls; confusing IaaS and PaaS boundaries; treating a certification as proof that customer-side controls operate; ignoring exit and data-portability design.