5.3 Respond & Remediate

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.

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.

flowchart LR
  A[Incident created] --> B[Automation rule evaluates conditions]
  B --> C[Set owner + severity in Sentinel]
  B --> D[Run playbook]
  D --> E[Logic App: isolate device via Defender]
  D --> F[Logic App: disable account in Entra ID]
  D --> G[Logic App: notify SOC in Teams]

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:

1. Document findings in incident comments and complete all incident tasks.
2. Classify the incident (True/Benign/False Positive, Undetermined) with a reason.
3. Tune — adjust analytics rule thresholds or add suppression for confirmed noise.
4. Improve coverage — use the workbook/MITRE ATT&CK view and SOC optimization recommendations to close detection gaps revealed by the incident.
5. 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.

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.