Automation
This domain tests automation that removes repetitive responder work: Incident Workflows, Automation Actions, Runbook Automation, and auto-resolve. Questions focus on triggers, conditions, action types, and when human approval is required.
Core rules
- Incident Workflows are triggered by incident events such as triggered, acknowledged, resolved, priority changed, or note added, and run steps in order.
- Conditions scope a workflow by service, urgency, priority, or incident fields; without conditions a workflow may fire too broadly.
- Steps can be automated actions (HTTP request, script, integration action), manual steps, or approval gates. Manual steps pause the workflow until a responder completes them.
- Automation Actions are reusable definitions; Runbook Automation executes scripts on targets via Rundeck. They need credentials and permissions.
- Auto-resolve closes incidents after a configured time or when the underlying alert resolves, depending on configuration; it is not a substitute for diagnosis.
- Workflows should be idempotent and tested in a non-production service; failed steps should be visible.
Worked example
A P1 database incident triggers a workflow. Step 1 posts to the incident Slack channel. Step 2 runs a read-only diagnostic script via Runbook Automation and attaches output. Step 3 creates a Jira ticket. Step 4 is an approval gate: the incident commander must approve before a failover action runs. Step 5 resolves the incident only if the failover succeeds. Reasoning: the approval gate prevents destructive automation; conditions limit the workflow to P1 database services.
Traps
- Confusing workflows with escalation policies; escalation is about notifying people, workflows are about actions.
- Running destructive actions without approval or guardrails.
- Using a workflow trigger that fires on every incident; add conditions.
- Assuming auto-resolve is the same as alert resolution; auto-resolve is a timer or policy.