During a full disaster recovery test, the team discovers that the database recovery runbook refers to two servers that were decommissioned last year and omits a newer reporting replica. The team improvises and completes the test. What should happen next?
Select an answer to reveal the explanation.
Short Explanation
A DR test that finds problems did its job; the failure is not fixing what it found. You capture the lessons, correct the runbook, give each fix an owner, and prove it with a retest. Improvisation worked this time because the right people were in the room, and you can't count on that in a real disaster.
Full Explanation
The value of a disaster recovery test lies in the improvements it drives. A post-test review should capture lessons learned, including every discrepancy between the documented procedure and reality, then update the runbook and the plan to reflect the current environment, here removing decommissioned servers and adding the reporting replica, assign each correction an owner and due date, and verify the fixes with a follow-up test of the affected steps. Deferring the edits to an annual review leaves a known-inaccurate plan in place for up to a year, so a real disaster in the meantime would hit the same problems with possibly different people on hand. Marking the test passed because the team succeeded by improvising confuses outcome with readiness; success depended on knowledge outside the documentation, and the plan itself failed. Deleting the runbook and relying on experienced staff removes the documented procedure that allows recovery when those individuals are unavailable, which is exactly the situation many disasters create. Exam caveat: DR documentation must be kept current through change management, not only after tests. Operational check: confirm the updated runbook lists only current servers, link it to the change process so future infrastructure changes trigger a review, and schedule the retest.