After planned maintenance, 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 startup order like a church pew: the ushers decide who walks in first. You want the database to be seated before the app starts asking for data. Don't confuse that with affinity, which just puts seats near each other but doesn't control who moves when.
Full Explanation
Startup order is a hypervisor sequencing control: it gives each VM a position in the power-on sequence, so dependent tiers can be brought up in a predictable order after a host or cluster restart. Guest boot scripts can mask missing platform sequencing, so the platform setting is the deterministic control. It solves dependency timing, not placement, capacity, or storage layout. VM affinity governs whether VMs are co-located or separated on hosts; keeping database and application VMs together does not make one boot before the other. Resource reservations guarantee minimum CPU and memory entitlements during contention, but they do not delay or accelerate power-on. Storage policies describe desired performance, redundancy, or placement characteristics for disks and volume groups; they do not coordinate application-level boot dependencies. Exam caveat: do not confuse startup order with affinity, reservations, or storage policy placement when the issue is dependency sequencing. Operational check: set the database tier to boot first, then verify that application VMs enter a powered-on state only after the database VMs have completed boot.