A utilities billing database runs Multi-AZ RDS, but the city has never practiced failover and has no tested runbooks. What continuity gap should architects close first?
Select an answer to reveal the explanation.
Short Explanation
Multi-AZ without a drill is a fire extinguisher still sealed in plastic. Write the failover play, pull the pin on purpose, and prove apps reconnect before the real outage does it for you.
Full Explanation
Multi-AZ RDS improves database availability for utilities billing, but capability without practiced runbooks is an unproven continuity gap. Architects should document and regularly test failover runbooks including application reconnection, DNS or endpoint updates, and data validation so Multi-AZ behavior is proven under controlled exercises before a real event. Replacing Multi-AZ with single-AZ to avoid failover surprises reduces resilience instead of closing the readiness gap. Assuming Multi-AZ alone is a complete continuity program and skipping drills leaves staff unprepared when failover finally happens. Turning off automated backups because Multi-AZ supposedly replicates to tape confuses synchronous standby behavior with backup retention and point-in-time recovery. Exam caveat: Multi-AZ failover is typically within-Region; it does not replace cross-Region DR or backup testing. Operational check: schedule a maintenance-window failover drill, execute the runbook, confirm billing APIs reconnect, and capture actual failover duration versus targets. In municipal cloud governance, record the owners, success metrics, and rollback or restore contacts beside this technical choice so the next incident, budget review, or audit does not rediscover the decision from scratch under time pressure.