A bank runs multi-tier payments on EC2, RDS Multi-AZ and ALB in eu-west-1 with a 4-hour RTO and must prove recovery quarterly without disrupting production. Which disaster recovery testing approach validates RTO compliance with Resilience Hub?

The correct approach is right because scheduled Resilience Hub assessments continuously evaluate the multi-tier EC2, ALB and RDS Multi-AZ architecture in eu-west-1 against the defined 4-hour RTO policy, while versioned runbooks provide repeatable recovery steps whose execution time directly evidences compliance, and running FIS fault injection in an isolated non-production environment proves the procedure works under realistic failure such as AZ impairment without risking live payments. The pipeline-triggered approach fails by concept because tying assessments to deployments validates change safety, not time-based compliance, so a quiet quarter with no releases would leave the bank unable to prove quarterly recovery as auditors require. The backup-freshness approach fails by concept because measuring RDS snapshot age and point-in-time restore currency validates how much data could be lost, which is recoverability point logic, not how quickly the ALB, EC2 and database tiers can be restored to service within four hours. The live-traffic fault approach fails by concept because injecting faults through the production ALB path exercises real payment flows and risks failed transactions and breach of availability, violating the strict non-disruption constraint even though timing and cadence are otherwise correct. For the exam, remember Resilience Hub proves alignment to RTO and RPO policies but does not itself execute failover, so distinguish assessment cadence from actual backup or pilot-light mechanisms. As a practical check, confirm the Resilience Hub schedule shows quarterly passing assessments, verify the FIS experiment template is scoped to an isolated VPC with guardrails and rollback, and review runbook execution logs for end-to-end restoration under four hours.