Palo Alto Networks Certified Security Automation Engineer (PCSAE)PlaybooksMedium
A security operations team uses Cortex XSOAR for incident response. They have a critical playbook that, when an incident is closed, performs a series of cleanup actions, including updating external ticketing systems and archiving incident data. Due to compliance requirements, this cleanup playbook must ONLY execute when the incident's status is explicitly set to 'Closed'. If the incident is accidentally reopened or its status changes away from 'Closed' during the cleanup process, the playbook must stop. Which playbook condition configuration should be used at the start of the cleanup playbook?
- AA 'While' loop that continues as long as `incident.status == 'Closed'`.
- BA 'Condition' task checking `incident.status == 'Closed'` and if false, ends the playbook.
- CA 'Condition' task checking `incident.status == 'Closed'` and setting a flag for subsequent tasks.
- DA 'Conditional' sub-playbook call that only runs if `incident.status == 'Closed'`.
Show answer & explanationAnswer & explanation
Correct answer: B. A 'Condition' task checking `incident.status == 'Closed'` and if false, ends the playbook.
A 'Condition' task at the start of the playbook, explicitly checking for `incident.status == 'Closed'` and ending the playbook if the condition is false, directly fulfills the requirement to only proceed if closed and to stop if not closed.
Why the other options are wrong
- A. A 'While' loop is for repetitive tasks, not for a single initial check and potential termination. It would also need explicit logic to stop.
- C. Setting a flag doesn't inherently stop the playbook if the condition isn't met; subsequent tasks would still need to check the flag.
- D. While a conditional sub-playbook call would prevent the sub-playbook from running, the question refers to the cleanup playbook itself needing to start and potentially stop, implying a check within its own flow.
Playbook Entry Condition
A 'Condition' task placed at the beginning of a playbook to validate prerequisites (e.g., incident status, required data) and terminate execution if conditions are not met, ensuring tasks only run when appropriate.
- Acts as a gatekeeper for playbook execution.
- Prevents unnecessary or incorrect automation.
- Can use `incident` fields or context data for checks.
Memory trick: At the start, check the 'Condition' to see if the door is open.