11.4 Sentinel Playbook for SIEM, SOAR, and Hunting

Choose Sentinel for Cross-Source Security Operations

Microsoft Sentinel is the SC-900 product for security information and event management (SIEM) and security orchestration, automation, and response (SOAR). In exam language that means collecting data through data connectors, detecting threats with analytics rules, raising incidents, investigating with hunting, visualizing with workbooks, and automating response with automation rules and Logic Apps playbooks. If the prompt reads like a security operations center (SOC) workflow, Sentinel should be at the top of your list.

Sentinel is the rebrand of Azure Sentinel; expect the current name on the exam. A common trap is choosing a Defender product simply because the scenario contains a threat. Defender products protect and detect within specific workloads. Sentinel is chosen when the scenario asks to bring data together, correlate signals across sources, investigate incidents centrally, or automate response steps. Defender may produce useful alerts that flow into Sentinel, but Sentinel is the SIEM and SOAR layer in the SC-900 objectives.

Do Not Treat Sentinel as Every Security Answer

A disciplined verb-to-product mapping stops the over-selection of Sentinel:

• Use Sentinel when the action is centralize, correlate, investigate across sources, hunt, visualize, or automate response.
• Use Defender for Cloud when the action is assess cloud posture or protect cloud workloads.
• Use Defender for Endpoint when the action is protect or investigate endpoint devices.
• Use Microsoft Purview when the action is classify, retain, audit, or investigate data for compliance.

SC-900 does not require you to write queries, but it may expect awareness that Kusto Query Language (KQL) is associated with hunting and analytics in Microsoft security tooling. A question that mentions hunting queries or notebooks is signalling threat investigation rather than identity governance or compliance management, which points to Sentinel when the task is SIEM-driven investigation.

Sentinel in Zero Trust and Defense in Depth

Sentinel also appears in Zero Trust and defense-in-depth scenarios. An organization may already have identity controls in Entra, network controls in Azure, and workload protection in Defender, yet still need a central place to detect, investigate, and respond to threats spanning all of them. Sentinel fits that layered model because it can collect and analyze signals from many sources, including Microsoft and third-party products. It does not replace the controls that prevent or protect; it sits on top to detect, investigate, and respond.

When answer choices include both Sentinel and Microsoft Defender XDR, read the wording carefully. If the question asks for the experience that correlates Microsoft-native Defender signals into incidents in the Defender portal, Defender XDR may be the better match. If it asks for SIEM, SOAR, connectors to arbitrary sources, workbooks, hunting, or playbooks, Sentinel is the clearer answer. Microsoft is converging the Sentinel experience into the Defender portal, but for SC-900 the conceptual division still holds: XDR correlates Microsoft signals, Sentinel is the broad SIEM/SOAR that ingests everything.

This distinction is one of the most useful final-week product-selection drills you can run.

The SIEM and SOAR Lifecycle in Plain Terms

It helps to picture Sentinel as a pipeline so you can place any clue word on it. First, collect: data connectors pull logs and alerts from Microsoft services, Azure, on-premises systems, and third-party products into a Log Analytics workspace. Second, detect: analytics rules — including Microsoft-provided and scheduled rules — examine the collected data and raise alerts that group into incidents. Third, investigate: analysts triage incidents, pivot through related entities, and run proactive hunting queries written in KQL to find threats that no rule caught yet.

Fourth, visualize: workbooks turn the data into interactive dashboards for monitoring and reporting. Fifth, respond: automation rules apply consistent handling to incidents, and playbooks built on Azure Logic Apps execute actions such as isolating a device, disabling a user, or opening a ticket.

That five-stage pipeline maps directly onto the SIEM and SOAR acronyms. SIEM covers collect, detect, investigate, and visualize — the information-and-event-management half. SOAR covers respond — the orchestration-automation-and-response half. When a question stresses gathering and analyzing data from many sources, it is leaning on the SIEM side; when it stresses automatic, repeatable response actions, it is leaning on the SOAR side. Either way, the product is Sentinel.

Where Sentinel Stops and Other Products Start

Sentinel is powerful, which is exactly why over-selection is the dominant error. Sentinel does not enforce identity policy — that is Entra's Conditional Access. Sentinel does not assess cloud posture or generate a secure score — that is Defender for Cloud. Sentinel does not classify or retain documents — that is Purview. Sentinel does not protect a single endpoint or mailbox — those are Defender for Endpoint and Defender for Office 365. Sentinel's job is to sit above all of these, ingest their signals, and provide centralized detection, investigation, and automated response.

A clean mental rule: if the scenario asks you to prevent, protect, classify, or grant access, look outside Sentinel; if it asks you to collect, correlate, hunt, visualize, or automate across sources, Sentinel is your product. Drilling that boundary repeatedly is the single most effective way to stop losing security-operations questions to a plausible-but-narrower Defender choice or a tempting-but-unrelated compliance choice.