Cloud Architecture and Design
What the exam tests
The Cloud Architecture and Design domain tests whether you can select and justify cloud-native designs that meet availability, scalability, security, and cost constraints. Expect questions on well-architected pillars, multi-AZ and multi-region patterns, decoupling, and the shared responsibility model.
Core rules
- Design for failure: assume any component can fail; use redundancy, health checks, retries, and graceful degradation.
- Prefer loose coupling: queues, events, and managed services reduce blast radius and let tiers scale independently.
- Treat elasticity as a design property: keep web/app tiers stateless and push state into managed data stores.
- Document trade-offs: HA costs more than single-AZ; disaster-recovery tiers (backup/restore, pilot light, warm standby, active-active) map to RTO and RPO.
Worked example
A three-tier web app must survive one AZ loss with RTO under 15 minutes. Place an ALB across three AZs, an Auto Scaling group with minimum 3 instances (one per AZ), and an RDS Multi-AZ instance. Serve static assets from S3 behind CloudFront. Reasoning: losing one AZ leaves two ALB nodes, two app instances, and an RDS standby that is promoted automatically; the ASG replaces lost capacity. This meets high availability but not region loss-a warm-standby secondary region would be needed for that.
Traps
Do not confuse high availability with disaster recovery. A single NAT gateway undermines a multi-AZ design. Ignoring cross-AZ and data-transfer costs loses marks. A design with no health checks, retry logic, or idempotent recovery steps is incomplete even if the diagram looks right.