2.2 Configure Microsoft Sentinel Workspace
Key Takeaways
- Microsoft Sentinel is a cloud-native SIEM + SOAR that runs on top of an Azure Monitor Log Analytics workspace; only one Sentinel instance per workspace.
- Sentinel built-in roles escalate in capability: Reader (view) < Responder (manage incidents) < Contributor (author analytics rules); Playbook Operator runs playbooks.
- Retention tiers are Analytics (hot), Auxiliary/Basic, Archive (up to 12 years), and the 2026 Data lake tier for cost-efficient long-horizon KQL-job hunting.
- Commitment tiers trade a daily-volume commitment for a discounted ingestion rate versus Pay-As-You-Go.
- Azure Lighthouse is the mechanism for an MSSP or central SOC to manage Sentinel workspaces across multiple customer tenants with delegated, auditable access.
Why This Matters for SC-200
Microsoft Sentinel is Microsoft's cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform. The April 16, 2026 skills outline pulls Sentinel design directly into the SecOps environment domain, so expect scenario questions about which workspace topology, retention tier, and role fits a stated requirement. Getting the workspace architecture right is the foundation everything else (connectors, analytics rules, hunting) is built on.
Log Analytics Workspace: The Container
Microsoft Sentinel is not a standalone data store. It runs on top of an Azure Monitor Log Analytics workspace. The workspace holds the tables (for example SecurityEvent, SigninLogs, SecurityAlert, SecurityIncident) that Sentinel queries with Kusto Query Language (KQL).
Key facts SC-200 tests:
- One Log Analytics workspace can have only one Microsoft Sentinel instance enabled on it.
- Workspace selection drives data residency (region), cost, and retention.
- You cannot move a workspace between resource groups/regions easily, so workspace design is a planning decision, not a runtime one.
Onboarding Microsoft Sentinel
- Create (or select) an Azure Log Analytics workspace.
- Add Microsoft Sentinel to that workspace from the Azure portal or via the unified Defender portal.
- Connect data connectors (covered in 2.3) so logs flow into the workspace.
- Enable analytics rules, automation, and content from the Content hub.
Since the unified portal integration, Microsoft Sentinel can also be operated from security.microsoft.com alongside Defender XDR, giving a single incident queue. Only one Sentinel workspace can be the primary workspace surfaced in the unified portal at a time.
Sentinel Roles
Microsoft Sentinel uses Azure role-based access control (RBAC) layered on the workspace. Memorize these built-in roles and what they allow.
| Role | Can do | Cannot do |
|---|---|---|
| Microsoft Sentinel Reader | View data, incidents, workbooks, rules | Edit, run playbooks, manage |
| Microsoft Sentinel Responder | Reader + manage incidents (assign, change status, add comments) | Create/edit analytics rules |
| Microsoft Sentinel Contributor | Responder + create and edit analytics rules, workbooks | Manage role assignments |
| Microsoft Sentinel Playbook Operator | Run and manage playbooks | Read security data on its own |
| Microsoft Sentinel Automation Contributor | Used by automation rules to run playbooks (assigned to the Sentinel service) | General analyst use |
Exam tip: An analyst who must triage and close incidents but should not author detections needs Sentinel Responder, not Contributor. Running a playbook from an incident also requires Playbook Operator (plus an Azure Logic Apps permission on the playbook's resource group).
Data Retention, Archive, and Tiers
This is a heavily tested 2026 topic. Sentinel/Log Analytics data moves through tiers with different cost and query behavior.
| Tier | Purpose | Query behavior |
|---|---|---|
| Analytics (interactive) | Hot, frequently queried security data; powers analytics rules and hunting | Full interactive KQL; default retention up to 90 days free, configurable to 730 days |
| Auxiliary / Basic logs | High-volume, low-fidelity logs (e.g., verbose network/firewall) | Limited KQL, lower ingestion cost, short interactive retention |
| Archive | Long-term, low-cost retention beyond interactive period | Not interactively queryable; use search jobs or restore to bring data back |
| Data lake tier (2026) | Cost-efficient long-horizon storage for hunting and KQL jobs; integrates with Sentinel Graph | Query via KQL jobs / scheduled jobs rather than always-hot interactive search |
Total retention can be configured up to 12 years using archive. The Data lake tier, added in the April 16, 2026 update, is the answer when a scenario needs long-term, cost-efficient data kept available for hunting and KQL jobs rather than always-hot interactive search.
Commitment Tiers (Pricing)
Sentinel/Log Analytics ingestion is billed either Pay-As-You-Go (per GB) or via a Commitment Tier (capacity reservation, e.g., 100 GB/day, 200 GB/day, up to multi-terabyte tiers). Commitment tiers give a discounted effective rate in exchange for a daily-volume commitment; ingestion above the tier is billed at the same discounted rate. For SC-200, the correct cost-optimization answer for a SOC ingesting a predictable, high daily volume is to move from Pay-As-You-Go to an appropriate commitment tier, and to route low-value high-volume data to Auxiliary/Basic or the Data lake tier.
Workspace Architecture: Multi-Tenant and Lighthouse
Large or managed environments need a deliberate workspace topology.
- Single workspace — Simplest; one team, one tenant. Easiest correlation and lowest cross-charges.
- Multiple workspaces (one tenant) — Used for data residency, regulatory separation, or business-unit isolation. Cross-workspace KQL uses the
workspace()function; cross-workspace analytics rules are limited, so prefer fewer workspaces when correlation matters. - Multi-tenant with Microsoft Sentinel — A Managed Security Service Provider (MSSP) or large enterprise managing many Entra tenants.
- Azure Lighthouse — The mechanism that lets an MSSP or central SOC manage Microsoft Sentinel workspaces across multiple customer tenants from their own tenant with delegated, auditable access. This is the SC-200 answer for centralized cross-tenant SOC management.
Central SOC tenant
└── Azure Lighthouse delegation
├── Customer A tenant -> Sentinel workspace A
├── Customer B tenant -> Sentinel workspace B
└── Customer C tenant -> Sentinel workspace C
Exam tip: "Manage many customers' Sentinel workspaces from one console with delegated access" => Azure Lighthouse. "Separate data by region/regulation within one company" => multiple workspaces, accepting reduced cross-workspace correlation.
An analyst must be able to triage Microsoft Sentinel incidents — assign owners, change status, and add comments — but must NOT be able to create or modify analytics rules. Which built-in role should you assign?
A SOC must keep seven years of log data at the lowest possible cost while still being able to run scheduled KQL hunting jobs against it for the new Sentinel Graph experiences. Which retention option best fits?
A managed security service provider (MSSP) needs to operate Microsoft Sentinel workspaces that live in many different customer Entra ID tenants, from the MSSP's own tenant, with delegated and auditable access. What should they use?