A three-tier app on AHV uses a database, app server, and web server. During failover, the database must start before the app and web tiers. You need the recovery plan to start the VMs together in the correct order. What should you do?
Select an answer to reveal the explanation.
Short Explanation
Think of a dependency group like a startup choreography for your app: the recovery plan boots the members in the order you set. If you only group them for replication or placement, the VMs don't wake up in the right sequence. You want the recovery plan to know which tier is first, second, and third.
Full Explanation
A dependency group is the recovery-plan construct used to express application startup order. When a recovery plan or runbook executes, it can start grouped VMs as a unit and honor the configured sequence, so a database can power on before application and web tiers. This is an orchestration concern: the plan must know which services depend on which other services. A consistency group on a protection domain is about replicated write consistency and crash-consistent snapshots across VMs, not the order in which powered-on VMs initialize. Setting a power-on delay on individual VMs affects local hypervisor boot behavior, but it does not make a recovery plan treat the tiers as a coordinated application group or guarantee failover sequencing. Assigning VMs to the same project category influences placement, visibility, and policy association, not startup dependency, so it cannot control boot order during failover. Exam caveat: do not confuse replication grouping with runbook execution grouping; only the recovery-plan dependency relationship controls startup order. Operational check: after building the plan, perform a test failover and verify the event log shows the database VM powering on before the application and web VMs.