I85PREP
⌘ K
Module 15 study materials
Module 15 study resources

Module 15: Planning and Design

Module 15 · Work through your exam, one topic at a time.

All guide sections

Planning and Design

This domain tests how you turn validated requirements into an architecture and delivery plan that survive real constraints. Questions target architecture decisions, capacity, failure domains, recovery objectives, and review evidence.

Core rules

  • Start from requirements and constraints. Record each significant choice in an architecture decision record: context, options, decision, consequences.
  • Map dependencies and failure domains. Components sharing power, network, or an identity provider are not independent.
  • Design for failure: N+1 or better on critical paths, defined degraded modes, and graceful failure.
  • Set recovery objectives explicitly. RTO is maximum tolerable downtime; RPO is maximum tolerable data loss. Backup frequency alone is not an RPO.
  • Capacity planning uses peak, not average. Forecast peak, add headroom, then validate with a load test.
  • Security and operability are design inputs: least privilege, encryption, audit logging, and runbook feasibility.
  • Plan migration and rollback before build: dark launch, parallel run, data backfill, cutover window, reversal steps.
  • Use review gates: design review, threat model, and test strategy sign-off.

Worked example

A service handles 200 requests per second average, and peak is four times average, or 800 req/s. Target headroom is 30%, so design capacity is 1,040 req/s. Each node safely serves 250 req/s at the p95 target, so 1,040 divided by 250 is 5 nodes. With N+1, deploy 6. Now test a zone failure: if 2 nodes are lost, 4 nodes serve 1,000 req/s, below 1,040. Add one more node or reduce per-node load. Reasoning: peak, then headroom, then per-node capacity, then failure domain. That is planning rather than guessing.

Traps

  • Designing to average load and discovering peak behavior in production.
  • Treating backups as disaster recovery without a restore test or RPO.
  • Missing a shared dependency that turns two redundant components into one failure domain.
  • Writing the decision record after implementation to justify a choice.
  • Ignoring data migration time and rollback feasibility during cutover.

Key points

  • Architecture decision records capture context, options, decision, and consequences.
  • Failure domains determine real redundancy, not component count.
  • RTO and RPO must be explicit and testable.
  • Capacity planning uses peak load plus headroom.
  • Migration and rollback plans belong in design, not after build.