L17. Automating Response in Microsoft Sentinel: Automation Rules, Playbooks & Data Retention

Automation Rules

Automation rules are Sentinel's incident-level orchestration layer, deciding what happens the moment an incident is created or updated, without needing a full Logic App for simple actions:

• Trigger conditions: run when an incident is created, updated, or (for a specific analytics rule) when an alert fires, optionally filtered further by incident properties (severity, entity type, matched analytics rule)
• Order of operations: multiple automation rules run in a defined order, so a rule that suppresses noisy false-positive incidents can run *before* a rule that would otherwise assign every incident to the on-call queue
• Actions: change incident severity or status, assign an owner, add a tag, add a comment, or invoke a playbook for anything more complex than these built-in actions can express directly

Playbooks

A playbook is simply an Azure Logic App triggered by a Sentinel incident or alert, giving it access to the full Logic Apps connector ecosystem for response actions:

• Disable a compromised user account in Microsoft Entra ID
• Block a malicious IP at the firewall
• Post an incident summary to a Teams channel or create a ticket in an external ITSM system
• Enrich an incident with threat intelligence lookups before an analyst even opens it

Playbooks can be invoked automatically from an automation rule, or run manually by an analyst on demand from within an incident, giving both a "fully automated" and "human-triggered, one-click" path to the same response action.

Data Retention

Sentinel/Log Analytics data has a tiered retention and cost model:

• Interactive retention: data is immediately queryable with standard KQL performance; the first 90 days are included free as part of the Sentinel workspace, with additional interactive retention configurable (at cost) beyond that
• Long-term retention / Archive tier: data can be retained far longer at a much lower storage cost than interactive retention, but isn't immediately queryable through normal analytics rules or ad-hoc KQL
• Search jobs and restore: to actually query archived data, a search job runs an asynchronous query against archived data without rehydrating it, while a restore operation brings a specific time range of archived data back into an interactive table temporarily for full-performance querying, needed for a deep investigation covering older incidents than interactive retention alone would reach

Querying Microsoft Purview Audit in Defender XDR

Microsoft Purview Audit captures user and admin activity across Microsoft 365 workloads (mailbox access, SharePoint file activity, Teams actions). Rather than requiring a separate Purview compliance portal session, this audit data can be queried directly from within Defender XDR's unified investigation experience, letting a security analyst correlate Purview audit activity with Sentinel incidents and Defender alerts in one investigation flow instead of pivoting between two separate consoles mid-investigation. Exam tip: SC-500 tests the distinction between automation rules (fast, incident-level, built-in actions, and the thing that controls *ordering* between multiple automations) and playbooks (Logic Apps doing the actual heavy-lifting integration work), plus the retention/cost tradeoff between interactive (immediately queryable, 90 days free) and archived (cheap, long-term, requires a search job or restore to query).