During a planned failover, a recovery plan stops before completing all steps. You must determine which step failed or remained incomplete and why. Which source gives the most direct evidence?
Select an answer to reveal the explanation.
Short Explanation
Think of a recovery plan like a checklist: each step has its own pass, fail, or incomplete mark. If the plan stalls, you don't start guessing from VM power states or cluster alerts; you read the step status. That is where the failed action and its reason live.
Full Explanation
A recovery plan is an ordered runbook, so its execution view tracks each action as pending, in progress, completed, failed, or incomplete. When a plan stops, the plan step status is the authoritative source because it ties the failure to a specific action, such as powering on a VM, waiting for replication, or promoting a volume group, and surfaces the error returned by that action. This is different from data protection status: Protection Domain replication status shows whether data is consistent and ready for failover, but it does not tell you which recovery plan action failed. VM power states and task history can confirm symptoms, such as a guest not starting, yet they do not correlate the symptom to the plan step or provide the plan's own failure reason. Cluster health alerts may reveal an underlying condition, such as a storage warning, but alerts are general cluster telemetry and can be unrelated to the plan or arrive out of order. Exam caveat: distinguish what the recovery plan reports about its own execution from what the protected objects or infrastructure report about their state. Operational check: open the failed recovery plan execution, expand the step list, and compare the last completed step with the first failed or incomplete step before remediating the underlying object.