A payment platform must prove its multi-Region failover meets a 15-minute RTO before a regulatory audit, but the team fears real outages and has no measured recovery evidence. Failover uses Route 53 health checks to an active-passive API. Which failover testing approach safely measures achievable recovery time?
Select an answer to reveal the explanation.
Short Explanation
You can't claim 15 minutes without a stopwatch, and controlled fault injection gives you proof without chaos. FIS plus Route 53 shows exactly how failover behaves.
Full Explanation
The correct approach uses Fault Injection Service to simulate regional impairment in a controlled experiment that triggers the same Route 53 health-check-driven DNS failover used in production, capturing end-to-end duration from injection through DNS propagation to API health in the secondary Region without causing an uncontrolled outage and producing timestamped evidence that the 15-minute RTO is achievable. Checking recovery readiness validates architecture, replica status and readiness rules, which aids preparation, but this assessment verifies configuration rather than generating timed failover telemetry. Tabletop game days strengthen runbooks, roles and communication, yet discussion-based rehearsal relies on estimates rather than measured DNS and application recovery. Restoring cross-Region RDS snapshots proves the data layer can be rebuilt within objectives, but database recovery alone does not exercise health-check thresholds, TTL propagation or API activation that dominate active-passive recovery time. For exams, distinguish proving time-based recovery from proving design correctness, since audits require measured durations. Practically, confirm detection plus DNS plus warm-up fit within 15 minutes using CloudWatch, Route 53 health-check metrics and the FIS report.