Cloud Architecture Design and Planning
Cloud Architecture Design and Planning
This domain tests whether you can turn a business ask into a defensible design: capturing non-functional requirements, mapping them to architecture patterns, and documenting the trade-offs you accepted. Scenarios usually give you constraints - budget, latency, residency, a legacy dependency - and score whether your response honours all of them, not whether you named the newest service.
Start from requirements, not from services
- Separate functional from non-functional: availability, durability, latency, throughput, RTO/RPO, data residency, ceiling on monthly spend.
- Quantify everything. "Highly available" is not a requirement; 99.95% monthly is, and it equals roughly 21.9 minutes of allowed downtime.
- Inventory hard constraints early: regulators, existing contracts, team skills, on-premises network ranges, mainframe dependencies.
Anchor the design
- Use the well-architected pillars - operational excellence, security, reliability, performance efficiency, cost optimization, sustainability - as a scoring checklist against each candidate design, not as decoration.
- Decide the landing zone before the first workload: org/folder hierarchy, environment separation, central logging, guardrail policies, billing boundaries. These are the least reversible decisions you will make.
- Think in blast radius: zone, then region, then account/project, then global control plane. Every level needs a stated failure plan.
Worked example
A payments API needs 99.95% availability, RTO 30 minutes, RPO 5 minutes, and data must stay in-country. Reasoning: 99.95% allows about 21.9 minutes of downtime a month, which a multi-AZ single-region deployment typically meets, so cross-region active-active is over-engineering. RPO 5 minutes rules out nightly backups; it demands continuous replication or log shipping with measured lag. RTO 30 minutes means capacity must be pre-provisioned and the failover automated and rehearsed - a warm standby in a second zone with a tested runbook. Residency fixes the region and any DR copy must remain in the same jurisdiction. Output: multi-AZ active-active app tier, warm-standby data tier, one architecture decision record stating what was rejected and why.
Traps that cost marks
- Designing to five nines when the business cannot fund the operational discipline behind it.
- Confusing durability with availability.
- Choosing a service before stating the requirement it satisfies; exam items reward the justification.
- Treating the org hierarchy as an afterthought and then trying to retrofit environment isolation.