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?

In Nutanix Disaster Recovery, managed from Prism Central, a protection policy associated with a category creates recovery points on a schedule and replicates them to the recovery site. Those recovery points are the point-in-time data that a recovery plan consumes: when you run a failover, you choose a recovery point (by default the latest), and the plan restores the VMs from it before running its ordered steps. The recovery plan itself is orchestration only; it sequences VM power-on through stages, remaps networks and runs scripts or notifications, but it doesn't create the data it restores, so it cannot be the source of recovery targets. An alert rule for replication lag is an operational signal; it may warn that recovery points are stale, but it doesn't generate one. An asynchronous replication schedule is a transport setting inside the protection policy; what the plan actually uses is the recovery point that schedule produces, not the schedule. Legacy protection domain snapshots serve the same role for Prism Element protection domain workflows, but Prism Central recovery plans work with protection policy recovery points. Exam caveat: separate the data artifact (recovery point) from the automation artifact (recovery plan). Operational check: before failover, confirm the latest recovery point at the recovery site is within the RPO, then run the recovery plan against it.