Cloud Architecture Concepts and Design
What this domain tests
Cloud Architecture Concepts and Design tests whether you can map business and security requirements to NIST-style service models (IaaS, PaaS, SaaS), deployment models (public, private, hybrid, community), and reference architectures. You must reason about shared responsibility, multi-tenancy, elasticity, resiliency, portability, and data gravity rather than recite definitions.
Core rules and concepts
- NIST SP 800-145 defines essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service.
- Service model sets the control boundary: IaaS gives the customer OS, middleware, runtime, app, and data responsibility; PaaS moves OS/runtime to the provider; SaaS leaves configuration, identity, and data governance to the customer.
- Design for failure: assume component loss, use multi-AZ/region patterns, decouple with queues, and define RTO/RPO before selecting replication.
- Multi-tenancy is an economic and security design choice; isolation may be logical, network, or physical. Do not assume dedicated hardware.
- Portability requires avoiding proprietary lock-in where exit or regulatory movement matters; interoperability depends on open APIs and data formats.
Worked example
A regulator requires an application with sensitive data, a small security team, and predictable patching. Candidate A is IaaS with self-managed databases; Candidate B is PaaS with managed database, automatic patching, and private networking. The team lacks database hardening staff, so PaaS reduces operational risk, but the customer still owns identity, data classification, access review, and application code. Choose B with a contractual patch SLA and export plan for exit. The reasoning is control ownership plus capability, not a blanket preference for IaaS or SaaS.
Traps that cost marks
- Confusing deployment model with service model: private cloud can still be PaaS.
- Assuming the provider secures customer data, identities, and configurations.
- Treating multi-tenancy as inherently insecure or inherently isolated.
- Ignoring egress cost, latency, and data gravity in architecture decisions.
- Selecting multi-region without defining consistency, failover, and RPO.