A three-tier application runs on AHV VMs replicated to a second Nutanix cluster. During a planned failover, the database VM must power on before the application VMs, and a runbook should execute after boot. Which Nutanix DR object should an admin use to orchestrate this multi-VM failover?
Select an answer to reveal the explanation.
Short Explanation
Think of a Protection Domain like a shipping container: it holds the VMs, but it does not tell the crew what to do when the alarm goes off. A Recovery Plan is the orchestration wrapper that powers on your database first, starts the app tier next, and fires post-boot automation. You use it when failover has to be coordinated, not just copied.
Full Explanation
A recovery plan is the Nutanix DR object that turns replicated VMs into an ordered failover sequence. It references a protection domain, maps networks or IPs, sets power-on order and wait conditions, and can attach runbooks so post-boot tasks execute when the plan runs. That makes it the right choice when several VMs must come up as a service, such as database before application, instead of failing over in an arbitrary order. A protection domain is still needed because it defines which VMs are replicated together and shares a replication schedule, but grouping VMs alone does not define startup dependencies or automation. An async replication schedule controls how often data is sent to the remote site and helps meet an RPO, yet it does not manage failover sequencing. A NearSync replication schedule tightens recovery point objectives by using shorter replication intervals, but it is also a replication timing mechanism, not an orchestration layer for multi-VM recovery. Exam caveat: do not confuse the object that groups VMs for replication with the object that sequences failover and failback. Operational check: review the recovery plan’s VM order, network mappings, and attached runbooks before a planned failover.