DR planning documents for an existing tax system still describe retired data centers and omit current multi-AZ AWS resources. Which improvement is required?
Select an answer to reveal the explanation.
Short Explanation
If the DR binder still talks about a data center you sold, rewrite it for the AWS you run—and test on a schedule. Pretending yesterday’s map works, or waiting for a real fire, isn’t planning.
Full Explanation
DR planning documents for an existing tax system that still describe retired data centers and omit current multi-AZ AWS resources are operationally dangerous. Refreshing DR plans to match the deployed architecture, defining a test cadence, and exercising recovery against the live AWS design restores preparedness for municipal tax continuity. That improvement is required because continuous improvement includes keeping continuity plans truthful and practiced. Keeping the legacy data-center DR narrative unchanged for “auditor consistency” fails conceptually—auditors need accuracy about how recovery actually works today. Removing RTO/RPO targets from all documents fails by eliminating the measures that make recovery performance meaningful. Postponing DR alignment until after the next unplanned outage fails as learning only when citizens are already harmed. Exam caveat: a refreshed plan without tests is still incomplete; multi-AZ is not automatically multi-Region—state RTO/RPO that the current design can actually meet. Operational check: rewrite the DR plan to name current Regions, AZs, databases, and runbooks; schedule a restore or failover test; compare measured recovery to RTO/RPO; and file evidence for the next continuity review.