5.3 Respond & Remediate
Key Takeaways
Automation rules orchestrate incident handling natively in Sentinel (assign owner, change severity, run playbooks, add tasks, close incidents) and run in priority order on triggers
Playbooks are Azure Logic Apps workflows triggered by the Microsoft Sentinel incident, alert, or entity trigger to perform external actions such as isolating a device or blocking an IP
An automation rule can run a playbook, but the Sentinel resource's managed identity or service account needs the Microsoft Sentinel Automation Contributor and playbook permissions
Automation rules suppress recurring noise by automatically closing matching incidents, which is the recommended alternative to deleting analytics rules
Cross-workload correlation: Defender XDR streams its incidents into Sentinel via the connector, and bi-directional sync keeps status and ownership aligned for unified post-incident review
Automation Rules vs Playbooks
SC-200 frequently asks you to pick automation rule or playbook for a given response scenario. They are complementary, not interchangeable.
| Aspect | Automation Rule | Playbook |
|---|---|---|
| Built on | Native Microsoft Sentinel feature | Azure Logic Apps workflow |
| Best at | Orchestration inside Sentinel | Actions outside Sentinel |
| Typical actions | Assign owner, change severity, add tasks, run playbook, close incident | Isolate device, disable user, post to Microsoft Teams/ServiceNow, block IP at firewall |
| Triggers | Incident created/updated, alert created | Incident, alert, or entity trigger |
| Ordering | Runs in a configurable priority order | Invoked by an automation rule or manually |
Rule of thumb: if the action stays inside Sentinel (triage, tagging, suppression, task creation) use an automation rule; if it must reach another system (Endpoint, Entra ID, firewall, ticketing) use a playbook, usually called by an automation rule.
Running a Playbook on an Incident or Entity
A playbook is an Azure Logic Apps workflow that uses one of the Microsoft Sentinel Logic Apps triggers:
- Incident trigger — receives the full incident object (all alerts and entities); used for case-level response.
- Alert trigger — receives a single alert; used for granular response.
- Entity trigger — run on demand against one entity (an account or IP) from the investigation graph or entity page; ideal for targeted actions like "disable this user."
Playbooks run manually, from an automation rule, or on demand from an entity. Permissions are a classic exam point: the Microsoft Sentinel app/service identity needs the Microsoft Sentinel Automation Contributor role on the resource group containing the playbook, and the playbook's connections need rights in the target system (for example, the Defender for Endpoint API to isolate a device).
Suppression of Recurring Noise
When a benign activity repeatedly creates incidents, the correct response is not to delete the analytics rule (you would lose detection coverage). Instead, create an automation rule with conditions matching the noisy pattern (entity, title, tactic) and an action that automatically closes the incident with a Benign/False Positive classification and reason.
- Suppression keeps the detection live but silences the known-benign case.
- The closure reason feeds tuning metrics so the SOC can later refine the rule logic.
- Order matters: a suppression automation rule should run early (higher priority) so it closes before downstream notification rules fire.
Post-Incident Activities
After containment, the exam expects disciplined closure:
- Document findings in incident comments and complete all incident tasks.
- Classify the incident (True/Benign/False Positive, Undetermined) with a reason.
- Tune — adjust analytics rule thresholds or add suppression for confirmed noise.
- Improve coverage — use the workbook/MITRE ATT&CK view and SOC optimization recommendations to close detection gaps revealed by the incident.
- Lessons learned — update playbooks and tasks so the next occurrence is faster.
Cross-Workload Correlation with Defender XDR
Microsoft Sentinel and Microsoft Defender XDR (the extended detection and response platform unifying Defender for Endpoint, Identity, Office 365, and Cloud Apps) work as one fabric.
| Mechanism | Effect |
|---|---|
| Microsoft Defender XDR connector | Streams Defender XDR incidents and alerts into Sentinel |
| Bi-directional sync | Status, ownership, and closing classification stay aligned between Sentinel and the unified Defender portal |
| Unified incident | Sentinel-only alerts and Defender XDR alerts can be correlated into one incident for whole-attack visibility |
| Advanced hunting parity | Defender XDR raw tables (DeviceEvents, EmailEvents) become huntable alongside Sentinel logs |
For post-incident review, this means an analyst sees the full multi-stage attack — an email lure (Defender for Office 365), the endpoint detonation (Defender for Endpoint), and the lateral identity move (Defender for Identity) — inside one correlated incident, with status synced wherever the analyst works.
Exam trap: if Defender XDR incidents are not appearing in Sentinel, check the Microsoft Defender XDR connector is enabled and the incident-sync option is turned on — not the individual product connectors.
A benign internal vulnerability scan repeatedly triggers the same Microsoft Sentinel analytics rule and floods the SOC with incidents. What is the recommended response that preserves detection coverage?
Delete the analytics rule
Create an automation rule that matches the pattern and automatically closes the incident as Benign Positive
Lower the workspace data retention
Disable UEBA
An analyst needs a response action that disables a specific compromised user account in Microsoft Entra ID directly from the investigation graph. Which combination is correct?
An automation rule alone, because automation rules can call Entra ID directly
A playbook using the Microsoft Sentinel entity trigger, run on the account entity
A workbook with a drill-down parameter
A bookmark mapped to the account entity
Microsoft Defender XDR incidents are not showing up in Microsoft Sentinel even though individual product connectors (Defender for Endpoint, Defender for Identity) are enabled. What should you check?
That the Microsoft Defender XDR connector is enabled with incident sync turned on
That UEBA is enabled
That a workbook is published
That incident tasks are configured
Match each response capability to whether it is best implemented as an automation rule or a playbook.
Match each item on the left with the correct item on the right
Assign incident owner and change severity in Sentinel
Isolate a device via the Defender for Endpoint API
Automatically close recurring benign incidents (suppression)
Post an enriched alert to a Microsoft Teams channel
Sections you finish are checked off in the contents.