A DR team must restore a failed app to a recent point after a site outage. They also need a single workflow that powers on VMs in order, remaps networks, and notifies owners. In this Nutanix design, which capability supplies the point-in-time recovery targets that the workflow consumes?
Select an answer to reveal the explanation.
Short Explanation
Think of a PD snapshot as the photograph and a recovery plan as the script that turns the photo into a working app. You don't launch VMs from an alert or a replication schedule; you pick the snapshot as the recovery point. The trap is mixing the what-you-restore with how-you-restore.
Full Explanation
Protection Domain snapshots are the recovery points in Nutanix DR: they create consistent, timestamped copies of the VMs grouped in a PD, and a recovery plan selects one of those snapshots as the data target before running ordered recovery steps. The plan itself is orchestration only: it sequences VM power-on, network remapping, and notification actions around an existing snapshot, rather than creating the point-in-time data it restores. A recovery plan with startup and network steps describes the workflow, so it cannot by itself answer which data version is being recovered. An alert rule for replication lag is an operational signal; it may warn that copies are stale, but it does not generate or identify a restorable point. An async replication schedule defines how often changed blocks move to the secondary site; the schedule is transport policy, while the usable point is the resulting replicated snapshot associated with the PD. Exam caveat: on this exam, separate the data artifact (snapshot) from the automation artifact (plan). Operational check: before failover, verify the chosen PD snapshot timestamp and confirm the recovery plan is bound to that snapshot, not just to a replication schedule or alert.