A continuity plan states municipal systems must resume within 4 hours and lose no more than 15 minutes of data. Which pair correctly maps those targets?
Select an answer to reveal the explanation.
Short Explanation
RTO is the stopwatch for how fast you must be back online; RPO is how much recent work you can afford to lose. Four hours to resume and fifteen minutes of data loss map cleanly to RTO and RPO—not the other way around. Mixing them up builds the wrong backup and failover design.
Full Explanation
Recovery Time Objective (RTO) is the maximum acceptable duration to restore service after a disruption, and Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured backward in time from the incident. A municipal continuity plan that requires systems to resume within 4 hours and to lose no more than 15 minutes of data therefore maps cleanly to an RTO of 4 hours and an RPO of 15 minutes. Swapping those labels—treating RPO as restore speed and RTO as acceptable data loss—is a frequent exam and planning error that mis-sizes backup frequency, replication technology, and failover runbooks. Mean time between failures and mean time to repair describe component reliability statistics; they are useful engineering metrics but are not the business continuity targets stated in the plan. Counting availability zones or regions is an architectural tactic that may help meet RTO/RPO, yet those counts are not themselves the definitions of the objectives. Exam caveat: Cloud+ stems often reverse RTO and RPO wording to catch candidates who memorize letters loosely—always translate “how fast back up” versus “how much data may vanish.” Operational check: set backup or replication intervals tight enough for the 15-minute RPO, rehearse failover until measured restore time meets the 4-hour RTO for each critical citizen service, capture evidence from tabletops and technical tests, and update the continuity plan with owners and last successful exercise dates.