A statewide benefits system must continue serving citizens after a rare Region-wide disruption. Which approach best supports that disaster-recovery goal?
Select an answer to reveal the explanation.
Short Explanation
When the whole Region is the problem, another AZ in that same Region cannot save you—you need a second geographic Region. For a statewide benefits system, multi-Region design is how you plan disaster recovery and business continuity. Caching park maps at the edge or clinging to one AZ does not replace a recovery Region.
Full Explanation
A statewide benefits system that must continue serving citizens after a rare Region-wide disruption needs a multi-Region architecture so a second Region can support recovery. Region-level events are uncommon, but when continuity requirements demand surviving them, active/passive or active/active designs across Regions—with data replication, DNS failover (Route 53), and runbooks—are the appropriate disaster-recovery approach beyond Multi-AZ alone.
Keeping all primary systems in one AZ worsens resilience even inside a Region. Storing only CloudFront cached HTML while deleting Regional databases cannot preserve dynamic benefits eligibility state. Disabling cross-Region replication to “avoid confusing operators” undermines the very recovery capability leaders are asking for.
Exam caveat: Multi-AZ ≠ multi-Region. Multi-AZ handles AZ failure inside a Region; multi-Region addresses Region-level DR and global presence. Match the failure domain named in the stem.
Operational check: pick a secondary Region aligned with residency rules, replicate critical data with the appropriate service features, define health checks and Route 53 failover, rehearse cutover annually, and clarify whether the secondary is pilot-light, warm standby, or active-active so budget matches the benefits program’s RTO.