After a failover to the DR site, your AHV estate must bring database VMs online before dependent application VMs. Which configuration enforces that startup dependency without relying on guest scripts?
Select an answer to reveal the explanation.
Short Explanation
Think of recovery plan stages like boarding groups at the airport: group one gets on first, and nobody in group two moves until they're called. Put your database in the earlier stage and the app VMs after it. Affinity and HA reservation don't decide who boots first.
Full Explanation
Ordered startup after failover is a recovery plan feature in Nutanix Disaster Recovery. A recovery plan groups VMs or categories into stages; Prism Central powers on everything in the first stage, waits for the configured delay, and only then starts the next stage. Putting the database VMs in an earlier stage than the application VMs makes the platform enforce the dependency, so the order doesn't depend on boot scripts inside the guests. You can add a delay long enough for the database services to come up, and use in-guest scripts only for extra checks. VM affinity policies control which hosts a VM may run on; keeping database and application VMs on the same host does not make one boot before the other. HA resource reservation (Guarantee mode) holds back capacity so VMs from a failed host can restart, but it doesn't sequence power-on. Storage policies set encryption, compression, QoS throttling and replication factor for the VMs they cover; they don't bind one VM's boot to another's disks. Exam caveat: AHV has no general VM startup-order setting for host or cluster restarts, so a question about ordered startup points to recovery plan stages. Operational check: run a test failover and confirm in the recovery plan report that the database stage finished before the application stage started.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.