A 200-person fintech runs a trading API on EKS across two Regions with DynamoDB global tables. Auditors require quarterly proof that pod-isolation and Regional failover playbooks meet a 1-hour RTO. Testing must not disrupt live trading and must produce repeatable pass/fail evidence. Which testing procedure should the security lead recommend to validate the incident response plan's containment and recovery effectiveness?
Select an answer to reveal the explanation.
Short Explanation
You’re proving the fire drill works without disrupting live trading. In an isolated staging clone, pairing Resilience Hub assessments with FIS pod-isolation and Regional failover faults gives you timed, repeatable evidence that containment and recovery meet your RTO.
Full Explanation
A quarterly game day in an isolated staging clone succeeds because it meets the requirements together: the clone avoids disrupting live trading, FIS injection of pod-isolation and Regional failover faults tests containment and recovery rather than assuming they work, and Resilience Hub assessments provide repeatable pass/fail evidence against the one-hour RTO. Running those faults in live production may measure the response, but risks disrupting trading and violates the non-disruption requirement. Reviewing Resilience Hub estimates and playbooks in staging without injecting FIS faults checks plans and expectations, not demonstrated effectiveness, so actual isolation and failover times remain unproven. Injecting FIS faults for DynamoDB backup restores tests a different recovery mechanism, with different steps and timelines, rather than Regional failover using DynamoDB global tables. On exams, distinguish measured recovery from an estimate or document review, and ensure the tested recovery mechanism matches the required scenario. In practice, verify that the clone reproduces relevant IAM permissions, routing, and global-table replication, then retain the FIS experiment report and Resilience Hub RTO timeline together as the repeatable evidence package.