Automation and Playbook Development
This domain tests building safe, maintainable playbooks in the Cortex XSOAR playbook engine. Expect questions about task flow, context data, error handling, and approval gates for destructive actions.
Core playbook rules
- A playbook is a sequence of tasks, commands, conditions, and sub-playbooks that read and write incident context.
- Triggers bind playbooks to incident types, severities, or labels. Avoid overlapping triggers that run duplicate automation.
- Design for idempotency: repeated execution should not create duplicate tickets, blocks, or notifications.
- Add error branches, timeouts, and checks for missing context keys. Never assume a prior task populated a field.
- Require human approval before isolation, account disablement, mailbox purge, or deletion.
- Test with mock incidents and review the War Room output for command errors and auditability.
Worked example
A phishing playbook starts on incident creation: extract indicators from the email, check reputation, detonate attachments, and branch on the verdict. If malicious, create block-indicator tasks and notify the analyst; require approval before purging the mailbox. If a task fails, route to a manual review task rather than continuing silently. The reasoning is that automation should accelerate safe decisions, not remove accountability for destructive actions.
Traps that cost marks
- Hardcoding API keys or credentials in scripts or tasks.
- Ignoring task errors so the playbook “completes” with missing data.
- Referencing context keys that may not exist.
- Automating containment without an approval gate.
- No deduplication, causing repeated blocks and ticket spam.