Implementation, Deployment, and Operations Support
What this domain tests
This domain tests whether the architecture can be built, released, and run - and whether you supply what operations needs to keep it running.
Core rules
- Architecture runway: identify enablers (platform, pipelines, observability) that must exist before features can land, and schedule them explicitly.
- Deployment strategies: rolling (cheap, mixed versions), blue-green (fast rollback, double cost), canary (real-traffic measurement, needs good telemetry). Deployment is not release - feature flags separate the two.
- Infrastructure as code with immutable images makes environments reproducible; configuration drift defeats diagnosis.
- Observability means metrics, logs, and traces correlated by request ID, aligned to SLIs and SLOs with error budgets. Without it, "it's slow" cannot be resolved.
- Disaster recovery is specified by RTO (how long without service) and RPO (how much data loss), which drive tier and cost. High availability is not DR: HA handles component failure, DR handles site loss.
- Supply runbooks, dependency maps, capacity models, tested restore procedures, and a rollback plan.
Worked example
A regulator requires claims processing to resume within four hours with at most fifteen minutes of data loss. RTO four hours and RPO fifteen minutes rule out nightly backups (RPO 24 h) and cold standby (RTO days). The answer is warm standby with continuous log shipping and automated failover, tested quarterly. Derive the tier from the numbers, then test the claim - an untested recovery plan is a hypothesis.
Traps
- Confusing deployment with release.
- Equating high availability with disaster recovery.
- Deferring non-functional enablers until after feature deadlines.
- Presenting a rollback or restore plan that has never been exercised.