A metro government runs a complex multi-Region citizen portal and wants Associate-level readiness checks that confirm Regional stacks can take traffic before a planned failover. Which capability class should architects be aware of?
Select an answer to reveal the explanation.
Short Explanation
Think of readiness checks as a pre-flight list before you hand traffic to another Region. Application Recovery Controller concepts help you see if the standby stack is actually ready—not just drawn on a slide. Skipping health and readiness is flying without instruments.
Full Explanation
A metro government running a complex multi-Region citizen portal needs more than diagrams before a planned failover. Architects should be aware of Route 53 Application Recovery Controller readiness concepts that help assess whether multi-Region resources are prepared to take traffic. Readiness checks evaluate whether capacity, replicas, and configuration in the standby Regional stack look prepared, reducing the chance that DNS is flipped to an incomplete civic portal.
Disabling all Route 53 health checks permanently to prevent unintended DNS changes fails because it removes failure detection and does not prove Regional readiness. Storing recovery runbooks only in the primary Region’s instance store fails when the primary Region is the one you are failing away from. Using a single AZ Auto Scaling group as the only multi-Region readiness control fails conceptually: one AZ ASG neither spans Regions nor measures standby readiness across dependent resources.
Exam caveat: readiness checks inform go/no-go decisions; they do not replace game days that actually shift traffic and validate citizen journeys. Operational check: define readiness criteria for each Regional dependency (compute, data, secrets, DNS), review readiness before planned failover windows, and couple checks with a controlled Route 53 traffic shift rehearsal.