City council shortened RTO for the citizen benefits portal from days to a few hours. The current DR method is backup and restore into an empty Region. Which DR improvement best fits the new objective?
Select an answer to reveal the explanation.
Short Explanation
Backup/restore is the slow boat; a few-hour RTO needs a pilot light already warm in the other Region. Replicate the crown jewels and keep a small flame ready to fan when council’s clock is ticking.
Full Explanation
City council shortening RTO for the citizen benefits portal from days to a few hours outgrows a backup-and-restore-into-empty-Region posture. Upgrading toward a pilot light—or warmer—posture with core data replicated and minimal critical capacity ready to scale out in the recovery Region best fits the new objective. That DR improvement works because cold backup/restore rarely meets few-hour RTOs once restore, config, and scale-out time are included. Keeping backup/restore only and waiving the new RTO in the next budget cycle fails governance after council set the objective. Deleting standby AMIs and IaC templates to simplify the recovery account fails by removing the very artifacts pilot light needs. Moving exclusively to a cold tape archive in a single on-premises vault fails RTO and cloud DR alignment. Exam caveat: pilot light still needs automated data promotion, DNS cutover, and scaled capacity plans; without automation, “pilot light” becomes slow manual restore under another name. Operational check: replicate core benefits data continuously or near-continuously, keep minimal compute/IaC ready in the recovery Region, execute a timed failover drill against the few-hour RTO, and fund gaps the drill exposes.