This chapter covers Security Orchestration, Automation, and Response (SOAR) workflows within Microsoft Sentinel, a critical component for the SC-200 exam. You will learn how to automate incident response using automation rules and playbooks, reducing manual effort and accelerating threat remediation. Approximately 15-20% of exam questions touch on Sentinel automation, making this a high-yield topic. Mastery of SOAR concepts, playbook design, and integration with Logic Apps is essential for passing the exam and for real-world security operations.
Jump to a section
Imagine a factory that produces custom furniture. The factory receives orders (incidents) from customers. Each order goes through a series of automated stations: first, an order is registered and classified (e.g., 'table' vs 'chair'). Then, based on the type, a specific assembly robot (playbook) is triggered. For a table, the robot might first check inventory for wood, then cut pieces to size, then assemble, then apply finish. Each step is automated, but if a step fails (e.g., wood is out of stock), the robot can pause and notify a human supervisor (analyst) who can manually intervene or approve an alternative. The factory also has a 'rush order' queue for high-priority incidents. After completion, the order is shipped and the entire process is logged for audit. Similarly, Microsoft Sentinel's SOAR capabilities use automation rules to trigger playbooks (Logic Apps) that execute a series of actions—like investigating, containing, and remediating threats—without manual intervention, but with options for human approval when needed.
What is SOAR and Why It Exists
SOAR stands for Security Orchestration, Automation, and Response. In Microsoft Sentinel, SOAR capabilities allow you to automate responses to security incidents, reducing the workload on analysts and ensuring consistent, rapid action. The key components are:
Automation Rules: Simple, rule-based triggers that can automatically assign, tag, or run playbooks on incidents.
Playbooks: Collections of automated actions, built on Azure Logic Apps, that can perform complex investigations, containment, and remediation.
SOAR addresses the challenge of alert fatigue and slow manual response times. For example, a brute-force attack generating hundreds of alerts can be automatically investigated and mitigated within seconds, rather than waiting for an analyst to triage each one.
How SOAR Works Internally
When an incident is created or updated in Sentinel, it triggers an evaluation of all active automation rules. Each rule has conditions (e.g., severity equals High, provider equals Azure) and actions (e.g., assign to a specific analyst, run a playbook). If conditions are met, the actions are executed.
Playbooks are Logic Apps that can be triggered by automation rules or manually. They use connectors to interact with various services—Microsoft 365 Defender, Azure AD, third-party firewalls, etc. A playbook can:
Get additional context (e.g., user information, IP reputation)
Perform actions (e.g., disable a user account, block an IP)
Create a Teams message or email for approval
Update the incident with findings
Playbooks execute in a sequence of steps, with support for loops, conditions, and parallel actions. They can be synchronous (wait for each step) or asynchronous (fire-and-forget).
Key Components, Values, Defaults, and Timers
Automation Rules: - Trigger: When incident is created, when incident is updated. - Conditions: Based on incident properties: Status, Severity, Owner, Tags, Title, Description, ProviderName, Tactics, Techniques, etc. - Actions: Assign incident to owner, change status, change severity, add tags, run playbook (up to 5 playbooks per rule). - Order: Rules are evaluated in ascending order (1-1000). Lower numbers run first. You can reorder via the portal. - Expiration: Optional expiry date/time for the rule.
Playbooks: - Trigger: Microsoft Sentinel Incident trigger (for incident-based playbooks) or Microsoft Sentinel Alert trigger (for alert-based playbooks). - Connectors: Over 400 connectors available in Logic Apps, including Azure Sentinel, Office 365, Teams, ServiceNow, etc. - Permissions: Playbooks use managed identity or service principal to authenticate. For Sentinel actions, the Logic App must have Contributor permissions on the Sentinel resource group. - Execution Time: Playbooks have a timeout of 1 hour for synchronous calls; asynchronous calls have no timeout but cannot return results to Sentinel. - Throttling: Logic Apps have limits: 30 concurrent runs per connector per region, 100 concurrent HTTP requests per connector. For high-volume scenarios, use batching or rate limiting.
Default Values:
Automation rules are enabled by default when created.
Playbooks are disabled until you enable them.
The default trigger for playbooks is the Incident trigger.
Configuration and Verification Commands
While most configuration is done via the Azure Portal, you can use PowerShell or Azure CLI for automation. For example, to list all automation rules in a Sentinel workspace:
Get-AzSentinelAutomationRule -ResourceGroupName "myRG" -WorkspaceName "myWorkspace"To create a playbook, you typically use the Logic Apps Designer in the portal. However, you can deploy playbooks from ARM templates or via CLI:
az logic workflow create --resource-group myRG --name myPlaybook --definition @playbook.jsonTo test a playbook, you can run it manually from the Sentinel Automation blade or from the Logic App itself.
Interaction with Related Technologies
Microsoft 365 Defender: Playbooks can pull advanced hunting data from M365D using the Advanced Hunting connector.
Azure AD: Playbooks can disable users, reset passwords, or check sign-in logs.
Microsoft Teams: Playbooks can send adaptive cards for approval workflows.
Third-party SIEMs: Playbooks can integrate with Splunk, Palo Alto, etc., via API connectors.
Azure Functions: For complex logic, playbooks can call Azure Functions.
Best Practices
Use automation rules for simple, high-confidence actions (e.g., auto-assign high severity incidents to senior analysts).
Use playbooks for multi-step investigations and responses.
Implement approval steps for destructive actions (e.g., disabling a user).
Use incident triggers for playbooks that need to update the incident; use alert triggers for high-volume, low-context actions.
Monitor playbook failures using Log Analytics workspaces and set up alerts for failures.
Exam Tips
Know the difference between automation rules and playbooks: automation rules are simple condition-action pairs; playbooks are complex workflows.
Remember that automation rules can trigger playbooks, but playbooks cannot trigger automation rules.
Understand that playbooks are Logic Apps; they are billed separately from Sentinel.
Be aware that playbooks have a 1-hour timeout for synchronous execution.
Know the default order of automation rules (by number) and that you can reorder them.
Remember that automation rules can have up to 5 playbook actions.
Common Misconfigurations
Running playbooks without proper permissions: The Logic App must have Contributor on the Sentinel resource group to update incidents.
Using alert trigger for playbooks that need incident context: Alert triggers only see the alert, not the full incident.
Not handling errors: Without error handling in Logic Apps, a single failure can stop the entire playbook.
Overusing automation rules: Too many rules can cause conflicts; order matters.
Summary
SOAR in Sentinel enables efficient, automated incident response. By combining automation rules and playbooks, you can reduce manual effort and response times. For the SC-200 exam, focus on understanding when to use each, how they are configured, and their integration with other Azure services.
Create an Automation Rule
Navigate to Microsoft Sentinel > Automation > Create > Automation rule. Provide a name and order number (e.g., 100). Set the trigger: 'When incident is created' or 'When incident is updated'. Define conditions: e.g., 'Severity equals High' and 'Provider equals Azure Active Directory'. Then add actions: e.g., 'Assign to owner: SecOpsTeam', 'Add tag: Auto-triage', 'Run playbook: BlockIP-Playbook'. Save the rule. It will be evaluated for every new/updated incident. The rule runs in order; if multiple rules match, all actions from all matching rules execute.
Design a Playbook in Logic Apps
From Automation > Playbooks > Add playbook. Choose 'Create a playbook' to open Logic Apps Designer. Select the trigger: 'Microsoft Sentinel Incident' or 'Microsoft Sentinel Alert'. For an incident trigger, the playbook receives the incident entity. Add steps: e.g., 'Get user details' using Azure AD connector, 'Check IP reputation' using VirusTotal connector, 'Condition: if reputation is malicious, then block IP via firewall connector'. Use parallel branches for independent actions. Add a 'Send approval email' step to Teams or Outlook. Finally, add 'Update incident' to add comments or change status. Save and enable the playbook.
Connect Playbook to Automation Rule
After creating the playbook, you need to grant it permissions to access Sentinel. Go to the Logic App > Identity > System assigned > turn On. Then assign the Logic App the 'Microsoft Sentinel Contributor' role on the Sentinel resource group or workspace. Next, in the automation rule, when adding the 'Run playbook' action, the playbook must appear in the dropdown. If it doesn't, ensure the playbook is enabled and you have the correct permissions. You can also use 'Run playbook' action with a specific version (by triggering a new version). The automation rule will invoke the playbook when conditions are met.
Test the Playbook Manually
In the Logic App designer, select 'Run Trigger' > 'Run with payload'. Provide a sample incident payload (JSON) that mimics a real incident. You can copy a sample from the Sentinel documentation. The playbook will execute step by step. Monitor the run history to see each step's inputs and outputs. Check for any errors (e.g., connection failures, missing permissions). After successful test, go to Sentinel and create a test incident that matches the automation rule conditions. Verify the playbook runs automatically and the incident is updated as expected.
Monitor and Troubleshoot Playbook Runs
In Logic Apps, each run is logged. Go to the Logic App > Runs history. Each run shows status (Succeeded, Failed, Running). Click on a run to see detailed steps. For failures, check the failed step's error message. Common issues: authentication errors (check managed identity permissions), throttling (reduce parallel actions or increase limits), timeout (simplify playbook or use asynchronous patterns). Use Log Analytics to query playbook run logs: `AzureDiagnostics | where ResourceProvider == 'MICROSOFT.LOGIC'`. Set up alerts for failed runs to ensure timely remediation.
Enterprise Scenario 1: Automated Phishing Incident Response
A large enterprise receives hundreds of phishing alerts daily from Microsoft 365 Defender. Manual triage is slow and inconsistent. Using Sentinel SOAR, they create an automation rule triggered when an incident is created with Tactics equal to 'Initial Access' and Provider equal to 'Microsoft 365 Defender'. The rule runs a playbook that:
Extracts the email sender and recipient from the incident entities.
Uses the Microsoft Graph connector to check if the sender is in the user's contact list (if not, higher suspicion).
Uses VirusTotal to check the URL reputation.
If malicious, the playbook automatically deletes the email from the recipient's mailbox (via Graph API) and adds a comment to the incident.
If suspicious, it sends an approval request via Teams to the security team.
In production, this reduces response time from 30 minutes to under 2 minutes. The playbook handles 500+ incidents daily without failure. Key considerations: the playbook uses managed identity with 'Mail.ReadWrite' and 'User.Read.All' Graph permissions. Throttling is managed by using pagination for large mailboxes. The automation rule is ordered first (order 10) to ensure it runs before other rules.
Enterprise Scenario 2: Brute-Force Attack Mitigation
A financial institution faces frequent brute-force attacks against Azure AD. They create an automation rule for incidents from 'Azure Active Directory Identity Protection' with severity High. The playbook:
Gets the risky user and IP address from the incident.
Checks if the user is a privileged role (e.g., Global Admin) using Azure AD connector.
If privileged, the playbook sends an SMS to the CISO for manual approval before disabling the user.
If non-privileged, it automatically disables the user account and blocks the IP at the firewall (via Azure Firewall connector).
Updates the incident with actions taken.
Scale: 200 incidents per day. Performance: the playbook completes in 30 seconds. The main challenge is handling false positives—users who are legitimately locked out due to forgotten passwords. To mitigate, the playbook includes a condition that checks sign-in logs for multiple failed attempts from different IPs; if only one IP, it might be a false positive and only triggers a warning. Misconfiguration example: forgetting to assign the Logic App the 'User Administrator' role to disable users causes frequent failures.
Enterprise Scenario 3: Insider Threat Investigation
A healthcare organization uses Sentinel to detect data exfiltration via DLP alerts. The automation rule triggers on incidents with Tactics 'Exfiltration'. The playbook:
Retrieves the user's recent activity (file downloads, emails) via Microsoft 365 logs.
Checks if the user has left the company or is under investigation (via HR system API).
If high risk, it automatically revokes the user's access to sensitive apps (via Conditional Access policy update).
Creates a ticket in ServiceNow for HR follow-up.
Sends a Teams notification to the security team.
Scale: 10 incidents per day (low volume but high criticality). The playbook uses asynchronous calls to avoid timeout when querying large log volumes. The main risk is accidentally revoking access for a legitimate user; therefore, the playbook includes a 5-minute delay and an 'undo' action if a false positive is reported. Common mistake: not updating the incident with a summary, making it hard for analysts to see what was done.
What SC-200 Tests on SOAR Workflows
The SC-200 exam objective 'Configure automation using Microsoft Sentinel' (Objective 2.5) covers:
Create and manage automation rules (trigger conditions, actions, order)
Create and manage playbooks (Logic Apps, triggers, actions, connectors)
Configure permissions for playbooks (managed identity, RBAC)
Test and troubleshoot playbooks
Integrate with Microsoft 365 Defender, Azure AD, and third-party systems
Common Wrong Answers and Why Candidates Choose Them
'Automation rules can trigger playbooks, and playbooks can trigger automation rules.' This is false. Playbooks cannot trigger automation rules; only incident creation/update can. Candidates confuse the bidirectional triggering of some SOAR platforms.
'Playbooks must use the Incident trigger for all automation.' Actually, you can use Alert trigger for high-volume, simple actions. Candidates overgeneralize from common use cases.
'Automation rules can have an unlimited number of playbook actions.' The limit is 5 playbooks per rule. Candidates assume no limit because the UI allows adding many actions, but only the first 5 playbook actions run.
'Playbooks can be created directly in Sentinel without Logic Apps.' Playbooks are Logic Apps; they must be created in Logic Apps. Sentinel provides a link to the Logic Apps designer. Candidates think it's a built-in Sentinel feature.
Specific Numbers, Values, and Terms on the Exam
Automation rule order: 1-1000 (lower number runs first)
Maximum playbook actions per rule: 5
Playbook timeout for synchronous calls: 1 hour
Playbook trigger types: 'Microsoft Sentinel Incident' and 'Microsoft Sentinel Alert'
Permissions required for playbook to update incidents: 'Microsoft Sentinel Contributor' on the resource group
Default expiration: none (you must set explicitly)
Edge Cases and Exceptions
If multiple automation rules match, all actions from all matching rules execute. Duplicate actions (e.g., two rules assign different owners) will overwrite; the last assignment wins.
Playbooks triggered by automation rules run asynchronously. The automation rule does not wait for the playbook to finish.
If a playbook fails, the automation rule still succeeds. You must monitor playbook runs separately.
Alert-based playbooks cannot update incidents because they don't have incident context.
Playbooks can be triggered manually from the incident blade (even if not associated with an automation rule).
How to Eliminate Wrong Answers
If a question asks about automating a multi-step investigation, the answer is 'playbook', not 'automation rule'.
If a question involves updating the incident (e.g., adding comments), the playbook must use the Incident trigger.
If a question asks about ordering, remember that automation rules are evaluated in ascending order by the number you assign.
If a question asks about permissions, look for 'Microsoft Sentinel Contributor' role on the Logic App.
If a question mentions high volume (e.g., thousands of alerts), consider using Alert trigger playbooks or batching to avoid throttling.
Automation rules are simple triggers that can assign, tag, or run playbooks on incidents; they are evaluated in ascending order (1-1000).
Playbooks are Azure Logic Apps that automate complex response actions; they must have 'Microsoft Sentinel Contributor' permissions to update incidents.
Playbooks have a 1-hour timeout for synchronous execution; for long-running tasks, use asynchronous patterns or split into multiple playbooks.
Automation rules can run up to 5 playbooks per rule; all matching rules execute their actions in order.
Use Incident trigger for playbooks that need full incident context; use Alert trigger for high-volume, low-context actions.
Monitor playbook failures using Logic Apps run history and set up alerts in Log Analytics.
Playbooks can integrate with Microsoft 365 Defender, Azure AD, Teams, and third-party systems via connectors.
The SC-200 exam tests the difference between automation rules and playbooks, their capabilities, and permissions.
These come up on the exam all the time. Here's how to tell them apart.
Automation Rules
Simple condition-action pairs
No coding required; configured via UI
Can assign, tag, change status, and run up to 5 playbooks
Evaluated in order (1-1000)
Limited to incident creation/update triggers
Playbooks
Complex, multi-step workflows built on Azure Logic Apps
Require Logic Apps knowledge; can include code via Azure Functions
Can perform any action supported by connectors (hundreds available)
No inherent ordering; triggered by automation rules or manually
Can be triggered by incidents or alerts; can also be scheduled
Mistake
Automation rules can run playbooks synchronously.
Correct
Automation rules always trigger playbooks asynchronously. The rule does not wait for the playbook to finish. Playbooks themselves can have synchronous steps, but the trigger is fire-and-forget.
Mistake
Playbooks can be created and managed entirely within Microsoft Sentinel without leaving the portal.
Correct
Playbooks are Azure Logic Apps. While you can launch the Logic Apps designer from Sentinel, the playbook creation and management occur in the Logic Apps service. Sentinel just provides a link.
Mistake
An automation rule can have an unlimited number of conditions.
Correct
An automation rule can have up to 5 conditions (combined with AND/OR). Each condition can have multiple values (e.g., severity equals High, Medium).
Mistake
Playbooks automatically have permission to update Sentinel incidents.
Correct
Playbooks need explicit permissions. You must assign the Logic App's managed identity the 'Microsoft Sentinel Contributor' role on the workspace or resource group. Without it, the playbook cannot update incidents.
Mistake
Alert-based playbooks can access full incident details.
Correct
Alert-based playbooks only receive the alert that triggered them, not the parent incident. They cannot update the incident or access other alerts within the incident. Use Incident trigger for full context.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An automation rule is a simple condition-action pair that runs when an incident is created or updated. It can assign the incident, change its status, add tags, or trigger up to 5 playbooks. A playbook is a complex workflow built on Azure Logic Apps that can perform multiple steps, such as querying external systems, making decisions, and taking actions like blocking a user or updating the incident. Automation rules are for quick, predefined responses; playbooks are for detailed, multi-step automation.
You need to assign the Logic App's system-assigned managed identity the 'Microsoft Sentinel Contributor' role on the Sentinel resource group or workspace. First, enable the managed identity in the Logic App under Identity > System assigned. Then go to the Sentinel resource group in Azure, select Access control (IAM), add role assignment, choose 'Microsoft Sentinel Contributor', and select the Logic App. This allows the playbook to update incidents, add comments, etc.
Yes. A playbook can be associated with an automation rule (so it runs automatically when the rule's conditions are met) and can also be triggered manually from the Sentinel incident blade. Manual trigger is available for any playbook that uses the Incident trigger. This allows analysts to run the playbook on-demand even if the automation rule didn't fire.
All automation rules that match the incident will execute their actions in order of their assigned number (lowest first). For example, rule 10 runs first, then rule 20. If two rules both assign an owner, the last one to run overwrites the previous assignment. Similarly, if two rules both add tags, all tags from both rules are added. Playbooks from all matching rules are triggered asynchronously.
Playbooks called by automation rules have a synchronous timeout of 1 hour. If the playbook does not complete within 1 hour, it fails. For longer-running tasks, you should design the playbook to use asynchronous patterns (e.g., split the work into multiple playbooks or use a queue). Note that the automation rule itself does not wait for the playbook to finish; it triggers it and continues.
Yes, a playbook can create a new incident using the 'Create incident' action in the Microsoft Sentinel connector. However, this is typically used for enrichment or correlation scenarios. Be careful to avoid infinite loops (e.g., a playbook creates an incident that triggers an automation rule that runs the same playbook again).
You can test a playbook manually from the Logic Apps designer by selecting 'Run Trigger' and providing a sample payload. Sentinel provides sample incident JSON in the documentation. You can also create a test incident in Sentinel (e.g., by generating a sample alert) and then manually run the playbook from the incident's 'Automation' tab. This allows you to verify the playbook works without affecting production.
You've just covered SOAR Workflows with Sentinel — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?