State what must recover before choosing a design
Recovery planning starts with a business operation and the disruption being considered. A running process, an available virtual machine and a completed customer transaction describe different endpoints. Choose the endpoint that reflects the actual requirement before timing a drill. Identify the application, data, identity, networking and other critical services needed for that operation. A diagram with two frontends can conceal one shared database or a missing credential. Replication can reduce particular failure risks, but it does not itself demonstrate that the complete business operation can resume under the chosen failure scenario.
Separate the acceptable outage from acceptable data loss
A recovery time objective, or RTO, describes the maximum acceptable time an application can be offline. A recovery point objective, or RPO, describes the maximum acceptable time window of data loss. These are separate business tolerances. A restoration can finish quickly while returning data that is too old; a recent data copy can exist while the service takes too long to become usable. Compare the measured recovery duration with the RTO and the recoverable data window with the RPO. The illustrative numbers in this course are fictional requirements, not recommended targets for every organization.
Test a restoration and the relevant application stack
A successful backup job is useful evidence about that job. It is not a demonstrated application recovery. Restore relevant data in a suitable non-production environment, check consistency and test whether the application and its critical services work with the recovered data. A matching record count or stored file size can miss broken relationships and unusable content. Define checks that matter to the operation. For order processing, that might include finding a recovered order and completing a permitted follow-up operation. These are original teaching examples of scoped testing, not universal product implementation instructions.
Worked example: measure the complete recovery path
A fictional service requires the user operation to resume within 30 minutes. Its database is restored in eight minutes, but credentials and application startup take another 34 minutes. The measured end-to-end duration is 42 minutes, so this exercise misses that recovery-time target. Keep the component timings because they show where investigation may help; do not substitute the fastest component for the full result. Department boundaries do not remove a critical dependency from the business endpoint. Record which data copy was restored as well, because the time result alone does not say whether the data-loss objective was met.
Make the exercise conditions and access explicit
A drill that removes one instance while all regional dependencies remain available tests that instance-loss case. It does not prove recovery after regional loss, data corruption or loss of the normal administrator access path. Document the relevant scenario, ordered recovery actions, expected objectives and authorized access needed to execute them. In an appropriate exercise, verify that designated responders can use the recovery tools and required credentials under the stated conditions. This does not call for bypassing access controls. It asks whether the authorized recovery arrangement remains usable when the normal environment is disrupted.
Transfer check: write a bounded recovery conclusion
A backup dashboard is green and two application zones are healthy. During a database-loss exercise, however, checkout cannot complete with the restored data. Explain why those dashboard observations do not settle the recovery question. Name the missing user-operation result, one data consistency check and the separate RTO and RPO comparisons. Then change the scenario to a single instance failure and state why the original database-loss result cannot automatically predict that different case. Use the linked practice to separate objectives, dependencies and evidence. Repeating the fixed tasks can support retrieval, but it does not calibrate professional readiness.
A restore test recreates the database in eight minutes, but dependent credentials and application startup take another 34 minutes. The requirement is to resume the user operation within 30 minutes of disruption. What should the report conclude?
- The business requirement specifies recovery of the user operation, not just a database restore step. The full measured duration is eight plus 34 minutes, or 42 minutes, beyond the 30-minute target. Ownership boundaries do not remove critical dependencies from that operation. Keep the component timings because they help identify improvements, but do not substitute the fastest component for the end-to-end result. This exercise establishes the tested case, not every possible disruption.
Compare the other answer choices
A component can restore within its own duration while the application still fails the user-facing recovery target.
Department ownership does not make required credentials and startup disappear from the business recovery path.
The business endpoint and complete 42-minute duration are already stated. Department-specific reporting cannot replace comparing that whole-operation result with its 30-minute target.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Disaster recovery planning guideTest recovery from data lossBuild highly available systems through resource redundancy | Cloud Architecture Center | Google Cloud Documentation