After a recovery plan fails over a multi-tier application from the production cluster to the DR cluster, the administrator sees the plan status as Completed. Which validation must be performed before declaring the failover successful?
Select an answer to reveal the explanation.
Short Explanation
Think of failover like flipping a light switch: the bulb isn't on just because the breaker moved. You have to prove the application actually answers health checks on the recovery site before calling it good. Don't confuse powered-on VMs with a running service.
Full Explanation
A recovery plan's completed status indicates orchestration finished, not that the workload is serviceable. The authoritative post-failover check is application-level validation: the application's health checks, probes, or dependent services must respond on the recovery site, confirming compute, storage, network, and guest services are usable after failover. Powered-on VMs with attached disks only prove the hypervisor presented the virtual hardware; a guest agent, service, or database may still be down. An absence of recent cluster alerts shows platform health, not application readiness, and may miss application-specific failures. Replication health on the source protection domain confirms data consistency and protection status, but it does not verify that the recovered copy is running or reachable. Exam caveat: a failover can report success at the recovery-plan layer while still requiring manual application validation before the business owner accepts it. Operational check: run the application's documented health check or a synthetic service probe against the recovery-site endpoint and record the result before closing the failover activity.