A bank must prove its multi-Region payment API meets a 15-minute RTO and 1-minute RPO for auditors. The architecture uses Route 53 failover, Aurora Global Database, and Application Load Balancers. Failover has never been tested under load. Which failover test design measures true recovery times for business continuity?
Select an answer to reveal the explanation.
Short Explanation
Auditors want stopwatch proof, not estimates, and you get that by breaking things safely. Fault Injection Service is your fire drill that times how fast Route 53 reroutes and Aurora recovers.
Full Explanation
The correct design succeeds because FIS blocking of primary Region traffic under load forces genuine Route 53 health-check failure, DNS failover, and redirection to secondary ALBs and Aurora Global Database, enabling direct measurement of payment RTO and RPO. The planned off-peak failover drill is valid for safe change control and DNS timing, but fails on load realism because low traffic never stresses ALB autoscaling, target health convergence, and Aurora promotion under peak throughput, so the 15-minute RTO remains unproven. The Aurora secondary promotion under load is excellent for data-layer RPO validation, but fails on full-stack scope because it isolates database lag from Route 53 detection, TTL propagation, and end-to-end payment recovery, so business RTO cannot be established. The synthetic load against secondary ALBs is standard for capacity assurance, but fails on failover causality because it tests standby performance without injecting failure or shifting live traffic, so no recovery interval is measured. Exam caveat is to distinguish component or capacity tests from business-continuity proof, since auditors require timed detection-to-recovery under load, not isolated health. Practical check is to align FIS injection timestamps with Route 53 health status, secondary ALB healthy-host counts, Aurora global lag, and restored transaction success rate for auditable evidence.