You create an X-Play playbook in Prism Central. Step 1 discovers a VM UUID from a cluster query, and step 2 must use that UUID to power off the VM. How should the discovered identifier be carried between the steps?
Select an answer to reveal the explanation.
Short Explanation
Think of a playbook like a relay race: the baton is the data, and variables are the handoff. You want the UUID captured in step one to be available in step two, so you stash it in a playbook variable. Don’t confuse inputs with variables; inputs are what you ask for before the race starts.
Full Explanation
Playbooks are stateful workflow engines, so values produced by one task can be retained and referenced by later tasks. The intended mechanism is a playbook variable: an early task writes the discovered cluster or VM identifier into the variable, and a downstream task reads that variable as a parameter or predicate. This keeps the workflow reusable because the identifier is supplied at runtime rather than hard-coded into each step. A playbook input is not the right mechanism when the value is discovered during execution; inputs are prompts evaluated before the run begins, so they cannot carry output from step one to step two. A REST API endpoint is an external programmatic interface for invoking or querying platform services, not an internal handoff object inside a single playbook. A Prism alert action is a notification or remediation trigger attached to monitoring events; it may consume identifiers from an alert payload, but it is not the workflow primitive used to pass data between playbook steps. Exam caveat: choose the feature that persists state across tasks, not the feature that starts the workflow or notifies operators. Operational check: in the playbook editor, define the variable, map the first task output to it, and confirm the later task references the variable rather than a static UUID.