Design and Configure a Microsoft Sentinel Workspace

Plan the workspace before you turn Sentinel on

Picture the most common Sentinel design mistake: a team spins up three regional workspaces "to be safe," then spends months writing cross-workspace queries and duplicating analytics rules that would have been one rule in one workspace. The rule that prevents it is simple: centralize into as few workspaces as you can, and add a workspace only when a hard boundary forces it. Everything else on this page (who can read the data, how long it is kept) is a property of the workspace you choose here, so this is the decision to get right first.

Microsoft Sentinel runs on top of an Azure Monitor Log Analytics workspace^[1]. A Log Analytics workspace is the indexed log store and query environment behind Azure Monitor; enabling Sentinel on it adds the SIEM and SOAR layer (analytics rules, incidents, hunting, automation) but stores everything in that same workspace. You enable Sentinel from the portal by selecting an existing or new workspace, and a single workspace can host only one Sentinel instance. Because region and workspace scope are effectively fixed once data flows in, planning them up front is the whole job of this section.

Choose the region first, for residency and cost

A Log Analytics workspace lives in one Azure region, and the data ingested into it is stored in that region^[2]. Pick the region that satisfies your data-residency obligation and that is close to where your data sources sit, because egress between regions adds cost and latency. A single global workspace cannot satisfy two conflicting regional residency rules at once; that conflict is one of the few legitimate reasons to run more than one workspace.

Default to one workspace; split only on a real boundary

Microsoft's workspace design guidance^[3] is to consolidate into as few workspaces as possible. One workspace means analytics rules, incidents, hunting, and the investigation graph all see the same data without cross-workspace plumbing, and you pay one set of overhead. Add a workspace only when one of these boundaries applies:

Data residency: sources whose data must stay in different regions.
Separate Microsoft Entra tenant: a workspace is tied to one tenant's identity boundary; you cannot merge tenants into one workspace.
Ownership, chargeback, or compliance isolation: business units or customers that must not see each other's data, or that need isolated retention.

For watching many tenants at once (a managed security service provider, or a company with several Entra tenants), the answer is not a shared workspace. Keep a workspace per tenant and use Azure Lighthouse^[4] for delegated, cross-tenant access, then query across them with cross-workspace queries. That preserves each tenant's isolation while giving the SOC one pane of glass.

Microsoft Sentinel workspace design: keep one workspace unless residency, tenant, or isolation forces a split (Microsoft Learn workspace best practices).

Sentinel roles and the Azure RBAC layers

Access to Microsoft Sentinel is Azure role-based access control (RBAC), and the single rule to internalize is that permissions stack: an analyst usually needs a Sentinel-specific role for incidents and analytics plus a Log Analytics role to read the raw data, because the two cover different things. Assigning subscription Owner to "make it work" is the over-permissioning trap this whole section exists to prevent.

One model: assign the narrowest built-in role at the workspace

Microsoft Sentinel ships built-in Azure roles^[5] you assign at the workspace, or at the resource group that contains it, so the grant covers Sentinel and nothing wider. From least to most privilege:

Microsoft Sentinel Reader: view data, incidents, workbooks, and other resources; cannot change anything.
Microsoft Sentinel Responder: everything Reader can do, plus manage incidents (assign, change status and severity, add comments). This is the everyday SOC analyst role.
Microsoft Sentinel Contributor: everything Responder can do, plus create and edit analytics rules, workbooks, and other content.
Microsoft Sentinel Playbook Operator: list, view, and manually run playbooks. Kept separate so you can let an analyst trigger a playbook without giving them rights to edit content.
Microsoft Sentinel Automation Contributor: lets Sentinel's automation rules run playbooks on your behalf; it is assigned to the Sentinel service identity, not to people.

Why a second role is usually required

The Sentinel roles grant rights on Sentinel constructs (incidents, rules, workbooks), but the events those constructs read live in Log Analytics tables. To read that underlying data a user also needs a Log Analytics read role such as Log Analytics Reader^[5] on the workspace. Conveniently, the Sentinel roles are built to be combined with Log Analytics roles, and a user who already has Log Analytics Contributor over the workspace gets the matching data access. The two-role pattern (Sentinel Responder + a Log Analytics read role) is the exam's canonical least-privilege answer for an analyst.

RBAC needed to configure, not just operate, Sentinel

Triaging incidents is operating Sentinel; standing it up needs broader rights. To enable Microsoft Sentinel on a workspace and connect data, you need Contributor on the subscription or resource group that holds the workspace at onboarding time, after which day-to-day work drops back to the narrow Sentinel roles. Connecting a data source needs Write permission on the workspace, and individual connectors can require extra permissions per their connector docs, so check each connector before wiring it up. Running a playbook manually needs only Sentinel Playbook Operator, but because a playbook is a Logic App, creating or editing one requires Logic App Contributor^[5] on the playbook's resource group. Grant configuration rights at install time, then scope people down to Reader, Responder, or Contributor for ongoing operations.

Sentinel roles nest: Responder adds incident management to Reader, Contributor adds content editing to Responder; Playbook Operator is a separate run-only role.

Log types and retention: the two-stage model

Two questions decide your Sentinel storage bill and your investigation power: which tier each table is on, and how long that data is kept. Get the rule first: assign each table the cheapest tier that still does the job, then keep it interactively only as long as you query it, and archive the rest. Tier and retention are set per table, so you tune them source by source rather than for the whole workspace.

Pick the log tier per table

Every table in the workspace has a table plan^[6] that sets what the data can do and what it costs:

Analytics logs: fully indexed, the only tier that powers scheduled analytics rules, the investigation graph, and the full KQL experience. Use it for the security signals you detect and hunt on. Highest ingestion cost.
Basic logs: a lower-cost tier for high-volume logs you search occasionally; queries are billed per query and the KQL surface is reduced, and Basic-tier data cannot trigger the standard scheduled analytics rules.
Auxiliary logs: the lowest-cost tier for verbose, low-value telemetry (for example raw network or firewall logs) you rarely touch, with the most limited query experience.

The design move is to keep the security-relevant tables (sign-ins, Defender alerts, security events) on Analytics so your rules and graph work, and push noisy, rarely-queried high-volume sources to Basic or Auxiliary to control cost.

Retention is interactive, then archive

Retention has two consecutive stages, and confusing them is the classic exam slip:

Analytics (interactive) retention: data is fully and instantly queryable with KQL. Analytics tables can be kept interactively up to 2 years (730 days). Basic and Auxiliary tables have only a total retention period (default 30 days, extendable), but they differ when you query: a Basic table has a fixed 30-day query window, while an Auxiliary table can be queried across its whole total retention period.
Long-term retention (archive): after the analytics period the data moves to a cheap, low-cost state in the same workspace, kept for up to 12 years total (4,383 days), which is the combined analytics-plus-long-term ceiling. Long-term data is not available for table-plan features; you reach it by running a search job^[7] or by restoring^[8] a table for a window back into the interactive tier.

Retention is configured per table, so a verbose audit log can sit on Basic with a long archive for compliance while your alert tables stay on Analytics with months of interactive history. Microsoft Sentinel also grants the data-retention setting a free allowance: when a workspace has Sentinel enabled, all data ingested into the workspace is retained free for the first 90 days^[9], so a 90-day interactive window adds no retention charge on top of ingestion. You set the workspace-level default retention and then override it per table where a specific source needs more or less.

Data lifecycle: interactive retention (queryable, up to 2 years) then archive (up to 12 years total); a search job or restore brings archived data back.

Exam-pattern recognition

This section maps the four blueprint tasks (plan the workspace, configure Sentinel roles, specify Azure RBAC for configuration, design data storage and retention) onto the question shapes SC-200 uses, with the right answer and why the tempting distractor is wrong.

"An analyst must triage and resolve incidents but should not edit analytics rules" -> Microsoft Sentinel Responder, plus a Log Analytics read role for the data. Sentinel Contributor is the over-grant distractor (it also lets them edit rules); subscription Owner is worse still.
"Let a user manually run a playbook without giving them content-edit rights" -> Microsoft Sentinel Playbook Operator (Logic App Contributor is only needed to create or edit the playbook). Giving Contributor would work but violates least privilege, which is the point of the question.
"Who can enable Microsoft Sentinel on a new workspace?" -> a user with Contributor on the subscription or resource group at onboarding. A bare Sentinel Reader or Responder cannot stand it up; those are operate-time roles, not install-time.
"Two business units must not see each other's data" or "sources in two regions with different residency rules" -> separate workspaces for the boundary. A single shared workspace is the trap: cross-workspace queries are cheaper than collapsing a residency or isolation boundary you cannot legally cross.
"One SOC must monitor 20 customer tenants" -> a workspace per tenant with Azure Lighthouse for delegated cross-tenant access. Merging all tenants into one workspace is wrong; a workspace is bound to one Entra tenant.
"Keep high-volume firewall logs for compliance at the lowest cost, rarely queried" -> Basic or Auxiliary tier with long-term archive retention. Leaving them on the Analytics tier with long interactive retention is the cost trap.
"Data must be searchable for 90 days then retained 7 years for audit" -> interactive retention for the 90-day window (free under Sentinel for the first 90 days), then archive to 7 years; retrieve with a search job. The distractor exports to a storage account, but in-workspace archive plus search job is the native answer.
"A scheduled analytics rule must run against this table" -> the table must be on the Analytics tier; Basic and Auxiliary logs do not drive standard scheduled rules. Picking Basic to save money breaks the detection.

Sentinel log tiers and what each is for

Property	Analytics logs	Basic logs	Auxiliary logs
Primary use	Security analytics, scheduled rules, hunting	High-volume logs queried occasionally	Verbose, low-value telemetry kept cheaply
Powers scheduled analytics rules	Yes	No (limited/near-real-time only)	No
Full KQL query experience	Yes, full indexing	Reduced (per-query billed)	Reduced, lowest cost
Analytics (interactive) retention	Up to 2 years (730 days)	Fixed 30-day query window	No separate window; queried over total retention
Total retention (incl. long-term)	Up to 12 years total	Up to 12 years total	Up to 12 years total
Relative ingestion cost	Highest	Lower	Lowest

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Microsoft Sentinel runs on a Log Analytics workspace

Microsoft Sentinel (formerly Azure Sentinel) is enabled on top of an Azure Monitor Log Analytics workspace, and that workspace stores all of Sentinel's logs, incidents, and analytics results. There is no separate Sentinel data store, so every workspace design choice about region, access, and retention is really a Log Analytics decision. A single workspace can host only one Sentinel instance.

Trap Treating Sentinel as its own database you can repoint later; the backing Log Analytics workspace and its region are fixed once data flows in.

Centralize into as few workspaces as possible

Microsoft's design guidance is to consolidate into the fewest workspaces you can, because analytics rules, incident correlation, hunting, and the investigation graph all work natively within one workspace and cost less than cross-workspace plumbing. Add a workspace only when a hard boundary forces it: a data-residency region, a separate Microsoft Entra tenant, or an ownership, chargeback, or compliance isolation requirement. Cross-workspace queries handle the rare cases where you must read across more than one.

Trap Spinning up one workspace per region or team by default; it multiplies rules and queries and is only justified by an actual residency, tenant, or isolation boundary.

A workspace is bound to one region and one Entra tenant

A Log Analytics workspace lives in a single Azure region and its ingested data is stored in that region, and it is tied to one Microsoft Entra tenant. Choose the region to satisfy data residency and to sit close to your sources, because cross-region transfer adds cost. A single workspace cannot meet two conflicting regional residency rules, which is one of the few legitimate reasons to run more than one.

Use Azure Lighthouse for multi-tenant, not a shared workspace

When one SOC or MSSP must monitor several Microsoft Entra tenants, keep a separate workspace per tenant and grant delegated access with Azure Lighthouse, then run cross-workspace queries for a single view. A workspace cannot span tenants, so merging tenants into one shared workspace is not possible and would break each tenant's isolation boundary.

Trap Collapsing multiple tenants into one shared workspace to simplify access; a workspace is bound to one tenant, so Lighthouse delegation is the supported cross-tenant path.

Sentinel access is layered Azure RBAC that stacks

Permissions for Microsoft Sentinel are Azure role-based access control assigned at the workspace or its resource group, and they combine rather than replace each other. A user typically needs a Sentinel-specific role for incidents and analytics plus a Log Analytics read role for the underlying tables, because the Sentinel roles grant rights on Sentinel constructs while the events live in Log Analytics. Assign roles at the workspace or resource group scope so the grant covers Sentinel and nothing wider.

Trap Assuming a single Sentinel role grants everything; without a Log Analytics read role the analyst cannot read the raw event tables behind the incidents.

Sentinel Reader is view-only

The Microsoft Sentinel Reader role lets a user view data, incidents, workbooks, and other Sentinel resources but change nothing. Use it for auditors or stakeholders who need visibility without the ability to act, and pair it with a Log Analytics read role so they can also query the underlying logs.

3 questions test this

Sentinel Responder is the analyst incident role

The Microsoft Sentinel Responder role adds incident management on top of Reader: assigning incidents, changing status and severity, and adding comments. It is the least-privilege answer for a SOC analyst who must triage and resolve incidents but should not edit analytics rules. Grant Responder plus a Log Analytics read role rather than the broader Contributor or subscription Owner.

Trap Granting Sentinel Contributor to an analyst who only triages incidents; Contributor also lets them create and edit analytics rules and content, breaking least privilege.

3 questions test this

Sentinel Contributor can edit rules and content

The Microsoft Sentinel Contributor role adds the ability to create and edit analytics rules, workbooks, and other Sentinel content on top of everything Responder can do. Reserve it for the engineers who build detections, not for analysts who only work incidents. It still does not grant the subscription or resource-group Contributor rights needed to first enable Sentinel.

6 questions test this

Playbook Operator runs playbooks without content rights

The Microsoft Sentinel Playbook Operator role lets a user list, view, and manually run playbooks, kept separate so you can let an analyst trigger a playbook without giving them rights to edit detections or content. Because a playbook is a Logic App, creating or editing one also requires Logic App Contributor on the playbook's resource group. The related Microsoft Sentinel Automation Contributor role is assigned to Sentinel's own service identity so automation rules can run playbooks, not to people.

Trap Granting Contributor just so someone can run a playbook; Playbook Operator (plus Logic App Contributor on the playbook resource group to edit it) is the least-privilege answer.

Enabling Sentinel needs Contributor at install time

To enable Microsoft Sentinel on a workspace and connect data, you need Contributor on the subscription or the resource group that holds the workspace, and individual data connectors can require extra permissions per their connector docs. These are install-time, configuration rights; once Sentinel is running, scope people down to the narrow Reader, Responder, or Contributor roles for day-to-day work. Specifying which Azure RBAC role enables versus operates Sentinel is a core blueprint task.

Trap Expecting Sentinel Reader or Responder to be able to onboard Sentinel; those are operate-time roles and cannot stand the workspace up.

Analytics tier is the only one that powers scheduled rules

Each table has a plan, and the Analytics tier is fully indexed and is the only tier that drives standard scheduled analytics rules, the investigation graph, and the full KQL experience, at the highest ingestion cost. Keep security-relevant tables such as sign-ins, Defender alerts, and security events on Analytics so detections and hunting work. Moving such a table to a cheaper tier to save money silently breaks the rules that depend on it.

Trap Putting a table a scheduled analytics rule queries onto the Basic or Auxiliary tier; those tiers do not drive standard scheduled rules, so the detection stops firing.

6 questions test this

Basic and Auxiliary logs are cheap tiers for high-volume telemetry

Basic logs are a lower-cost tier for high-volume data you query occasionally, with queries billed per query and a reduced KQL surface; Auxiliary logs are the lowest-cost tier for verbose, low-value telemetry such as raw network or firewall logs you rarely touch. Both default to a 30-day total retention, but they behave differently when you query: Basic tables have a fixed 30-day query window, while Auxiliary tables can be queried across their whole total retention period. Route noisy, rarely-queried sources here to control ingestion cost while keeping security tables on Analytics.

Trap Leaving verbose firewall or network logs on the Analytics tier with long interactive retention; the right cost move is Basic or Auxiliary plus long-term archive.

Retention is two stages: interactive then archive

Log retention has two consecutive stages. Interactive (analytics) retention keeps data fully and instantly queryable with KQL; Analytics tables can be kept interactively up to 2 years (730 days), while Basic tables have a fixed 30-day query window and Auxiliary tables are queried across their total retention. After the analytics period, long-term (archive) retention keeps the data cheaply for up to 12 years total (the combined analytics-plus-long-term ceiling). Set both per table so a verbose source can have short interactive plus long archive.

Trap Confusing interactive retention with the total ceiling; interactive caps at 2 years for Analytics, while long-term retention extends the combined total to 12 years.

1 question tests this

Your organization requires that authentication logs stored in the SigninLogs table of your Microsoft Sentinel workspace remain available…

Reach archived data with a search job or table restore

Archived (long-term) data is not interactively queryable. To use it you run a search job against the archive, or restore a table for a time window back into the interactive tier where normal KQL works again. This in-workspace archive plus search job is the native way to meet multi-year audit requirements, rather than exporting logs to a storage account.

Trap Reaching for an export-to-storage-account pattern to retain logs for compliance; in-workspace archive retention with a search job or restore is the built-in answer.

Sentinel grants the first 90 days of retention free

When a workspace has Microsoft Sentinel enabled, the first 90 days of data retention are free for all data ingested into the workspace, on top of the ingestion charge. A 90-day interactive window therefore adds no retention cost, which is why a common requirement of "searchable for 90 days, then retained for years" maps cleanly to free interactive retention plus paid archive.

1 question tests this

You enable Microsoft Sentinel on a new Azure Monitor Log Analytics workspace and configure data connectors to ingest security events into…

Set retention per table, with a workspace default

Retention is configured per table, layered over a workspace-level default you can override table by table. That lets a noisy audit log sit on a cheap tier with a long archive for compliance while alert tables stay on Analytics with months of interactive history. Designing this table-by-table data storage and retention is an explicit SC-200 blueprint task.

Split workspaces for residency or isolation, query across them

When sources fall under different regional data-residency rules, or two business units must not see each other's data, create separate workspaces for that boundary rather than one shared workspace, because a residency or isolation boundary cannot be legally crossed by consolidating. Use cross-workspace KQL queries to investigate across them when needed. Centralization is still the default; only the hard boundary justifies the split.

Trap Using a single shared workspace across a residency or data-isolation boundary to simplify queries; cross-workspace queries are the right tool, not collapsing the boundary.

Assign Sentinel roles at a dedicated resource group, not the workspace

Microsoft recommends deploying the Sentinel workspace into a dedicated resource group and assigning the built-in Microsoft Sentinel roles at that resource-group scope. Permissions are then assigned once and apply automatically to all dependent resources (the workspace, playbooks, workbooks), minimizing ongoing role-management effort.

Trap Assigning at the workspace scope leaves playbooks/solution resources uncovered and creates more assignments to manage.

9 questions test this

Roles assigned at the workspace scope must also be assigned on the SecurityInsights resource

If you assign a Sentinel role directly on the workspace instead of on the resource group, some Sentinel features break unless you also assign the same role on the SecurityInsights solution resource in that workspace (and potentially other dependent resources).

Trap This extra assignment is unnecessary when you assign at the resource-group scope, which is why RG-scope is the recommended pattern.

4 questions test this

Plan the workspace before you turn Sentinel on

Choose the region first, for residency and cost

Default to one workspace; split only on a real boundary

Sentinel roles and the Azure RBAC layers

One model: assign the narrowest built-in role at the workspace

Why a second role is usually required

RBAC needed to configure, not just operate, Sentinel

Log types and retention: the two-stage model

Pick the log tier per table

Retention is interactive, then archive

Exam-pattern recognition

Sentinel log tiers and what each is for

Decision tree

Cheat sheet

References