A Prism Central automation playbook provisions a workload VM by name. During a cleanup window the target VM was deleted, so the playbook fails at the first step because the object no longer exists. Which design change makes the playbook resilient without hiding unrelated failures?
Select an answer to reveal the explanation.
Short Explanation
Think of a playbook like a delivery driver: if the address is gone, a bigger engine won't help. Check that the VM exists first, then decide whether to skip or stop. That keeps you from treating a deleted object as a transport failure.
Full Explanation
A Nutanix automation playbook should validate that an object exists before performing operations that require that object. When a VM is deleted between design and execution, the API returns an object-not-found condition. A conditional existence check lets the playbook branch to a safe outcome, such as skipping the step, logging an informational event, or stopping before dependent actions. This distinguishes an expected lifecycle change from a real automation defect. Ignoring all failed steps hides the missing object and also suppresses unrelated problems such as permission, network, or policy errors, so the playbook may continue into an invalid state. Increasing timeout or retry count treats the failure as transient; a deleted VM is not a slow response, so retries only delay the same object-not-found result. Storing a static VM list creates a stale dependency and does not check the current inventory at runtime, so it can still reference deleted objects. Exam caveat: Nutanix automation questions expect you to separate transient API issues from deterministic missing-object conditions. Operational check: run the playbook against a known deleted VM and confirm the conditional branch logs or skips without marking unrelated steps as failed.