An AHV-hosted three-tier application must start DB, then app, then web after a planned cluster restart; shutdown must reverse. The admin needs a Prism Central workload control that enforces this sequence without manual VM-by-VM power actions. Which control should be used?
Select an answer to reveal the explanation.
Short Explanation
Think of tiered apps like a domino chain: if the database isn’t up, the app and web tiers just flail. You want startup policies to set the dependency order, then shut them down in reverse. Anti-affinity, storage QoS, and DR boot order won’t solve a routine planned restart.
Full Explanation
VM startup policies exist to express application-level boot dependencies rather than relying on arbitrary hypervisor recovery order. When a tiered workload has a database, middleware, and presentation tier, the policy records which VMs depend on which, and the platform sequences startup accordingly; shutdown can be defined to reverse that chain so dependent tiers stop before their backing services. This is a workload-management control because it changes how VMs are powered during planned cluster or host events, not where they run or how much storage throughput they receive. Anti-affinity placement rules spread VMs across AHV hosts to reduce correlated failure risk, but placement does not create a power-on dependency between tiers. Storage policies with QoS or performance tiers influence IOPS, latency, and capacity allocation, not VM boot sequencing. Recovery-plan boot order is appropriate for disaster recovery orchestration and failover, but it is not the normal control for planned restarts of production workloads in the primary cluster. Exam caveat: choose the feature that matches the trigger—startup policies for routine power events, recovery plans for DR. Operational check: after configuring the policy, validate the dependency graph and perform a controlled test restart of one tier group, confirming database VMs reach a ready state before application and web VMs power on.