This chapter covers Logic Apps playbooks for automating incident response within Microsoft Sentinel. Playbooks are a critical component of the SC-200 exam, appearing in approximately 15-20% of questions related to incident management and automation. You will learn how playbooks work, how to create and configure them, and how they integrate with Azure Logic Apps and other security tools. Mastery of this topic is essential for automating repetitive tasks and ensuring consistent response actions in a SOC environment.
Jump to a section
Imagine a large corporate building with a security operations center (SOC) that monitors hundreds of alarms. When an alarm triggers—say a fire alarm in the east wing—the SOC analyst must follow a specific procedure: verify the alarm, announce evacuation, call the fire department, and log the event. Instead of the analyst manually performing each step, they have a pre-written script that automatically executes the sequence: it first checks camera feeds to verify the alarm, then triggers the building-wide announcement, dials 911 with a pre-recorded message, and finally writes a report to the incident log. This script is a Logic Apps playbook. Just as the script can be triggered by the alarm system (an incident creation) and can interact with other systems (cameras, PA system, phone), a Logic Apps playbook is triggered by Microsoft Sentinel incidents and can call external services via connectors. The script can include conditions (e.g., if the alarm is in a high-risk area, also notify the safety officer) and loops (e.g., retry calling if the line is busy). The key is that the script is automated, consistent, and can be updated centrally, much like a playbook in Sentinel.
What are Logic Apps Playbooks and Why They Exist
Logic Apps playbooks are automated workflows that run in response to Microsoft Sentinel incidents or alerts. They are built on Azure Logic Apps, a cloud service that provides a visual designer to create and run workflows that integrate with various services. The primary purpose of playbooks is to automate incident response tasks, such as enriching alerts with threat intelligence, blocking malicious IPs, or notifying analysts. This reduces manual effort, speeds up response times, and enforces consistent procedures.
How Playbooks Work Internally
A playbook is triggered by a Sentinel incident or alert. The trigger can be either a webhook (for real-time triggers) or a scheduled trigger (for periodic tasks). When an incident is created or updated, Sentinel can automatically run a playbook via an automation rule. The automation rule specifies which incidents trigger which playbook. The playbook then executes a series of steps, each defined as an action in the workflow. Actions can include:
Connectors: Pre-built interfaces to services like Microsoft Teams, Azure AD, Exchange Online, or third-party APIs. Each connector has a set of actions (e.g., "Send an email").
Conditions: Logic that evaluates data and branches the workflow (e.g., if severity is high, block IP; else just notify).
Loops: Repeat actions over a collection (e.g., iterate through all IPs in an alert).
Variables: Store and manipulate data (e.g., store a threat score).
The workflow runs in Azure Logic Apps, which handles execution, retries, and error handling. Each step has a timeout (default 120 seconds for HTTP actions, configurable up to 24 hours). If a step fails, the playbook can retry (default 4 times with exponential backoff) or proceed to a failure handling path.
Key Components, Values, Defaults, and Timers
- Triggers: - When a response to an Azure Sentinel incident is triggered (webhook): Used for real-time automation. The trigger fires immediately when the incident matches the automation rule. - When an incident is created or updated (via Sentinel connector): Similar but uses polling; may have a delay of up to 5 minutes. - Actions: Each action has a timeout (default 120s for HTTP, 1 minute for other actions) and retry policy (default: 4 retries, exponential backoff starting at 7 seconds, max interval 1 hour). - Connectors: Over 400 connectors available. Key for SC-200: Sentinel connector, Azure AD, Microsoft Teams, Exchange Online, ServiceNow, and custom API connectors. - Automation Rules: Define triggers for playbooks. Each rule has: - Name: Up to 100 characters. - Trigger: When incident is created, updated, or both. - Conditions: Based on incident properties like severity, status, or custom tags. - Actions: Run a playbook (up to 10 playbooks per rule). - Order: Rules are processed in order; first match wins. - Playbook Limits:
Max number of actions per workflow: 500.
Max workflow run duration: 30 days.
Max payload size: 100 MB per action.
Configuration and Verification Commands
Playbooks are created in the Azure Portal under Logic Apps. To create a playbook for Sentinel:
In Azure Portal, search for "Logic Apps" and click "Add".
Choose the "Consumption" plan (not Standard) for Sentinel integration.
In the Logic Apps Designer, select the trigger "When a response to an Azure Sentinel incident is triggered".
Add actions (e.g., "Send an email" via Office 365 Outlook connector).
Save and assign permissions: The playbook must have the Sentinel Responder role on the resource group containing the Sentinel workspace.
To attach a playbook to an automation rule:
In Sentinel, go to "Automation" -> "Create" -> "Add new rule".
Set conditions (e.g., severity = High).
Under "Actions", select "Run playbook" and choose the playbook.
Apply.
Verification: Use the "Run history" tab in the Logic App to see each execution. Check for failures by filtering on "Failed" status. Use Azure Monitor logs to track playbook runs with KQL:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where OperationName == "Microsoft.Logic/workflows/workflowRunCompleted"
| project runId, status, startTime, endTimeInteraction with Related Technologies
Sentinel Incidents: Playbooks are typically triggered by incidents, not raw alerts. Incidents aggregate alerts and provide context.
Automation Rules: These are the bridge between incidents and playbooks. Rules can also trigger other actions like changing incident status.
Azure Logic Apps: The underlying engine. Playbooks are essentially Logic Apps workflows with a Sentinel-specific trigger.
Power Automate: Similar to Logic Apps but for Microsoft 365 users. Not directly integrated with Sentinel; use Logic Apps instead.
Azure Functions: Can be called from playbooks for custom code. Useful for complex logic not possible in the designer.
Exam Tip: Trap Patterns
Common wrong answers on the exam:
Confusing playbooks with automation rules: Automation rules trigger playbooks; playbooks are the workflows.
Thinking playbooks can run on alerts directly: They run on incidents. To run on alerts, you must first create an incident from the alert.
Assuming playbooks are created in Sentinel: They are created in Logic Apps and then imported to Sentinel.
Forgetting permissions: The playbook must have the Sentinel Responder role; otherwise, it cannot update incidents.
Create a Logic App Playbook
Navigate to Azure Portal > Logic Apps > Add. Choose the Consumption plan (not Standard) because Sentinel's trigger is only available in Consumption. Provide a name, subscription, resource group, and region. The region should be the same as your Sentinel workspace to minimize latency. After creation, open the Logic Apps Designer.
Add Sentinel Trigger
In the designer, search for 'Azure Sentinel' and select the trigger 'When a response to an Azure Sentinel incident is triggered'. This trigger uses a webhook to receive incident data in real-time. You must authenticate to your Sentinel workspace. The trigger outputs the incident properties (e.g., Incident ID, Title, Severity, Entities) as dynamic content for subsequent actions.
Define Actions for Response
Add actions using connectors. For example, to block an IP: use the Azure AD connector action 'Block user' or a custom connector to a firewall API. Each action can use dynamic content from the trigger. Set conditions: for instance, if severity is High, block the IP; else, only send a notification. Use parallel branches for independent actions.
Assign Permissions to Playbook
The playbook must have the 'Sentinel Responder' role on the resource group containing the Sentinel workspace. Without this, the playbook cannot update incidents (e.g., add comments, change status). In Azure Portal, go to the resource group > Access Control (IAM) > Add role assignment. Select 'Sentinel Responder' and assign it to the playbook's managed identity or service principal.
Create Automation Rule to Trigger Playbook
In Sentinel, go to Automation > Create > Add new rule. Define conditions: e.g., when incident is created with severity High. Under Actions, select 'Run playbook' and choose the playbook from the list. The rule can also trigger other actions like changing incident status. Rules are processed in order; only the first matching rule runs (unless you enable 'Continue running subsequent rules'). Save the rule.
In a large enterprise SOC, playbooks are used to automate the response to phishing incidents. When Sentinel detects a phishing email (via Office 365 ATP connector), it creates an incident. An automation rule triggers a playbook that:
Extracts the sender's email address and the malicious URL from the incident entities.
Blocks the sender in Exchange Online using the 'Block sender' action.
Submits the URL to Microsoft Defender for Endpoint for reputation check.
Posts a message in a Teams channel dedicated to phishing incidents.
Adds a comment to the incident with the actions taken.
This reduces response time from minutes to seconds and ensures consistent handling. Another scenario is automated IP blocking for brute-force attacks: a playbook extracts the source IP from the incident, checks it against internal threat intelligence, and if malicious, adds a block rule in the firewall via a custom API connector.
Common misconfigurations include:
Not assigning the Sentinel Responder role, causing the playbook to fail when trying to update the incident.
Using the wrong trigger (e.g., 'When a new alert is created' which is not available for Sentinel; instead use the incident trigger).
Forgetting to handle errors: if an action fails (e.g., firewall API is down), the playbook may stop. Best practice is to add parallel branches for error handling or configure retry policies.
Performance considerations: Playbooks have a maximum run duration of 30 days, but typically run in under a minute. For high-volume incidents, ensure the playbook is efficient—avoid unnecessary loops and use pagination for large datasets. Monitor run history for failures and use Azure Monitor alerts to notify the SOC when a playbook fails.
The SC-200 exam tests your understanding of playbooks under objective 'Automate responses using Microsoft Sentinel' (Domain 2, Objective 2.5). Key areas:
Playbook vs. Automation Rule: You must know that automation rules are the trigger mechanism; playbooks are the action. A common question: 'Which component runs a workflow when an incident is created?' Answer: Automation rule (not playbook directly).
Permissions: The exam frequently asks about required permissions. The playbook needs the 'Sentinel Responder' role. A trick: they might say 'Contributor' or 'Reader'—those are wrong.
Triggers: Know the two triggers: 'When a response to an Azure Sentinel incident is triggered' (webhook, real-time) and 'When an incident is created or updated' (polling, up to 5 min delay). The exam may ask which trigger is suitable for time-sensitive responses.
Connectors: Be familiar with common connectors: Office 365 (email, Teams), Azure AD (block user), and custom APIs. They might ask which connector to use to send a message to a Teams channel.
Limits: Default timeout for HTTP actions is 120 seconds. Max actions per workflow is 500. Know these numbers.
Common wrong answers:
Choosing 'Power Automate' instead of 'Logic Apps' for Sentinel automation. Power Automate is for Microsoft 365 workflows, not directly integrated.
Thinking playbooks can be triggered by alerts directly—they must be triggered by incidents.
Assuming playbooks are created in Sentinel UI—they are created in Logic Apps and then attached.
Edge cases: If an incident is updated, some automation rules may re-trigger. To prevent loops, use conditions to check incident status (e.g., only run on new incidents). The exam may test this with a scenario where a playbook updates the incident, causing another trigger.
Playbooks are Azure Logic Apps workflows triggered by Sentinel incidents via automation rules.
The playbook must have the 'Sentinel Responder' role on the Sentinel workspace's resource group.
Automation rules define conditions (e.g., severity) and actions (run playbook).
Use the Consumption plan for Sentinel playbooks; Standard plan does not support the required trigger.
Default HTTP action timeout is 120 seconds; retry policy is 4 retries with exponential backoff.
Playbooks can use over 400 connectors to integrate with Microsoft and third-party services.
The most common exam trap is confusing playbooks with automation rules or Power Automate.
These come up on the exam all the time. Here's how to tell them apart.
Consumption Logic App (Playbook)
Runs in multi-tenant Azure Logic Apps environment; billed per action.
Supports Sentinel trigger 'When a response to an Azure Sentinel incident is triggered'.
Maximum run duration 30 days; actions limited to 500.
No local storage; state managed by Azure.
Ideal for event-driven, short-lived workflows.
Standard Logic App
Runs in single-tenant environment; billed per hosting plan.
Does not support the Sentinel trigger; cannot be used as a playbook.
Supports longer run durations (up to 1 year) and more actions (up to 1000).
Includes local storage and VNet integration.
Ideal for complex, long-running integration workflows.
Mistake
Playbooks can be triggered directly from alerts.
Correct
Playbooks are triggered by incidents, not raw alerts. To automate on alerts, you must first create an incident from the alert using an analytics rule.
Mistake
Playbooks are created and managed within Microsoft Sentinel.
Correct
Playbooks are Azure Logic Apps workflows. They are created in the Logic Apps designer and then attached to Sentinel via automation rules.
Mistake
Any Logic App can be used as a playbook without special permissions.
Correct
The Logic App must have the 'Sentinel Responder' role on the Sentinel workspace's resource group to update incidents.
Mistake
Automation rules and playbooks are the same thing.
Correct
Automation rules define when to run a playbook (conditions and triggers). Playbooks are the actual workflow that executes actions.
Mistake
Playbooks can only be triggered by new incidents.
Correct
Playbooks can be triggered on incident creation and/or update, depending on the automation rule configuration.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An automation rule is a set of conditions and actions that runs when an incident is created or updated. It can trigger a playbook. The playbook is the actual workflow that performs automated steps. Think of the automation rule as the 'if this, then that' and the playbook as the 'that' (the sequence of actions).
No. Sentinel playbooks are built on Azure Logic Apps, not Power Automate. Power Automate is designed for Microsoft 365 automation and lacks the Sentinel-specific trigger. Always use Logic Apps Consumption plan.
The playbook (its managed identity or service principal) must have the 'Sentinel Responder' role on the resource group containing the Sentinel workspace. Without this, the playbook can trigger but cannot modify the incident (e.g., add comments, change status).
Check the Logic App's run history in the Azure Portal. Each run shows success/failure status and details of each action. Common issues: missing permissions, connector authentication failure, or timeout. Use Azure Monitor logs with KQL to query run failures.
No. Playbooks are designed to run on incidents. To automate on an alert, you must configure an analytics rule to create an incident from the alert, then use an automation rule to trigger the playbook on that incident.
Maximum 500 actions per workflow, run duration up to 30 days, payload size up to 100 MB per action, and default HTTP timeout of 120 seconds. Retry policy: 4 retries with exponential backoff starting at 7 seconds.
The incident trigger outputs dynamic content including Incident ID, Title, Severity, Status, and Entities. You can use these in subsequent actions by selecting them from the dynamic content picker in the Logic Apps Designer.
You've just covered Logic Apps Playbooks for Sentinel Automation — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?