A recovery plan protects production VMs from Site A to Site B. Site A loses power and is unreachable, but Site B has the latest replicated VMs. You need to bring the production VMs online at Site B as quickly as possible. Which action should you take?
Select an answer to reveal the explanation.
Short Explanation
Think of failover like evacuating a building: if the old site is gone, you don't wait for it to say goodbye. Run an ungraceful failover so the recovery plan brings your VMs online at the target. Waiting for a graceful failover only makes sense when the source can still be reached.
Full Explanation
Ungraceful failover is the recovery-plan action used when the protected source cluster cannot be contacted. It starts the target-side VMs and applies the plan's startup order, network mapping, and post-boot steps without requiring a shutdown or state confirmation from the unavailable source. That makes it appropriate for a total site outage, because the objective is rapid availability at the DR site rather than an orderly source-side shutdown. A graceful failover would be wrong here because it expects the source cluster to respond so the source VMs can be stopped cleanly and the plan can synchronize final state before starting the targets. Powering on protected VMs directly at the target bypasses the recovery plan's orchestration, which can miss network mappings, startup sequencing, or guest customization, and it leaves the DR workflow without proper state tracking. Performing a failback is also wrong because failback is the return movement after the source environment is healthy and replication has been re-established; it does not bring services online at the DR site during the outage. Exam caveat: choose the failover mode based on source reachability, not on whether the target has data. Operational check: confirm the recovery plan's target network mapping and guest boot settings before using ungraceful failover, then validate application startup.