An auditor asks which automation changed a VM's power state after a recent change window. You know an X-Play playbook and an external API script could both have done it. Which source should you use to identify the specific playbook run that changed the VM state?

Automated changes need a traceability record that identifies the workflow instance, not merely the low-level call. In a Nutanix environment, X-Play or playbook execution history is intended for that role: it associates a run, trigger, timestamp, parameters, and target VM with the state change that resulted. That makes it the right evidence when the audit question is which automated workflow changed the VM. API audit logs can prove that an API request reached Prism, but they are call-level records and may not include the workflow identity, especially when multiple playbooks or scripts use the same service account. CVM event logs describe infrastructure-level cluster and hypervisor events; they are useful for host or CVM diagnosis, not for naming a Prism automation workflow. NCC health checks evaluate configuration and operational health, so they may reveal symptoms after a change but they do not provide change attribution or workflow run history. Exam caveat: when the question asks for the workflow that made the change, choose the automation run/playbook history; choose API audit only when the question asks which API call or user/API key performed the action. Operational check: export the relevant playbook run history for the reported window and correlate the run ID, target VM, timestamp, and parameter set with the observed state change before responding to the auditor.