SC-200 Microsoft Sentinel Platform: Roles, Data Tiers, Retention, Workbooks and SOC Optimization
Configuring the Microsoft Sentinel platform means deciding who can do what (Sentinel, workbook, Entra and data lake roles), how long each table keeps its data and in which tier (Analytics, Data Lake or XDR default), how the SOC visualizes data in workbooks, and how SOC optimization recommendations trim cost and close coverage gaps. This SC-200 lesson covers each of those four official skills as they work with Sentinel in the Microsoft Defender portal, with the near-twin choices side by side.
On this page10 sections
- Microsoft Sentinel roles: Reader, Responder, Contributor, workbooks and guests
- Where to assign Sentinel roles, and why assignments add up
- Microsoft Sentinel data lake permissions
- The three tiers: Analytics, Data Lake and XDR default
- Choosing the Data Lake tier, and what stops working
- Extending XDR data: 90-day analytics retention and Data Lake-only ingestion
- What happens when you change retention
- The Tables page and the permissions to change it
- Creating and configuring Microsoft Sentinel workbooks
- SOC optimization: data value, coverage and similar organizations recommendations, and their status
- Choose the least-privileged Sentinel role (Reader, Responder, Contributor) and add Workbook Contributor or Directory Readers when the task needs it
- Assign Sentinel roles at the right scope and explain why role assignments are cumulative
- Pick the Microsoft Entra role that grants read or job access in the Microsoft Sentinel data lake
- Choose the Analytics, Data Lake or XDR default tier and set analytics and total retention for a cost and compliance requirement
- Predict the effect of retention changes and of moving a table to the Data Lake tier
- Create a workbook from a Content hub template or from scratch and configure its queries, refresh and export
- Interpret and manage SOC optimization data value, coverage and similar organizations recommendations
Microsoft Sentinel roles: Reader, Responder, Contributor, workbooks and guests
Microsoft Sentinel has three built-in Azure roles for people, and they are cumulative: Microsoft Sentinel Reader views, Microsoft Sentinel Responder adds incident management, and Microsoft Sentinel Contributor adds creating and editing content. Pick the lowest one that covers the job.
| Role | Adds | Typical holder |
|---|---|---|
| Microsoft Sentinel Reader | View data, incidents, workbooks, analytics rules and other Sentinel resources | Auditors, read-only reviewers |
| Microsoft Sentinel Responder | Everything Reader has, plus managing incidents: assign owners, change status and severity, add comments | Tier 1 and tier 2 analysts |
| Microsoft Sentinel Contributor | Everything Responder has, plus create and edit workbooks, analytics rules and other Sentinel resources, and install or update Content hub solutions | Security and detection engineers |
Two more Sentinel roles exist for narrower jobs. Microsoft Sentinel Playbook Operator lets a user list, view and manually run playbooks; Microsoft Sentinel Automation Contributor is a service role that lets Sentinel attach playbooks to automation rules and is not meant for user accounts. Playbook and automation permissions are covered in the Sentinel automation lesson.
The generic Azure Contributor role also lets someone edit Sentinel content, but it reaches every resource type in its scope, so it fails a least-privilege requirement when a Sentinel role would do. Managing Content hub content specifically needs Microsoft Sentinel Contributor at the resource group.
Workbooks and guest users
Reader and Responder can view workbooks but not create or save them; for that they need the Azure Workbook Contributor role on top of their Sentinel role. Microsoft Sentinel Contributor already includes workbook editing, so only add Workbook Contributor when the person must stay at Reader or Responder everywhere else. Workbook Reader only views.
Guest users need a directory role as well. Assigning an incident owner looks users up in Microsoft Entra ID. Member users can read the directory by default; Microsoft Entra B2B guests can't. So a guest who must assign incidents needs the Microsoft Entra Directory Readers role in addition to Microsoft Sentinel Responder. Directory Readers is an Entra role, not an Azure role, so no Azure role assignment, at any scope, gives directory read.
| Task | Roles needed |
|---|---|
| Triage and assign incidents (member user) | Microsoft Sentinel Responder |
| Assign incidents (guest user) | Microsoft Sentinel Responder + Directory Readers (Entra) |
| Create and save workbooks, otherwise read-only | Microsoft Sentinel Reader + Workbook Contributor |
| Create analytics rules, install solutions | Microsoft Sentinel Contributor |
Where to assign Sentinel roles, and why assignments add up
Microsoft recommends assigning Sentinel roles on the resource group that contains the Sentinel workspace. Playbooks (logic apps) and saved workbooks are separate Azure resources, so a resource-group assignment covers the workspace and every playbook and workbook in that group, including ones created later.
If policy forces resource-level assignments, assign the role on the Log Analytics workspace enabled for Sentinel and the same role on the SecurityInsights solution resource in that workspace. Other resources, such as each playbook's logic app, then need their own assignments. Subscription scope works too, but grants far more than one SOC needs.
Role assignments are cumulative. A user's effective permissions are the union of every assignment that reaches them, directly or through a group, at any scope from management group down to resource. A user who holds Reader on the resource group and Contributor through a group at the subscription effectively has Contributor. Adding another Reader assignment never removes rights; to cut access, remove the assignment that grants too much, or remove the user from the group that carries it when others still need that group.
Microsoft Sentinel data lake permissions
The Microsoft Sentinel data lake takes its broad permissions from Microsoft Entra ID roles, not from the Microsoft Sentinel roles. One Entra role assignment covers every workspace in the lake.
| Need | Entra roles that grant it |
|---|---|
| Read and run interactive queries across all workspaces, including system tables | Global Reader, Security Reader, Security Operator, Security Administrator, Global Administrator |
| Create and manage jobs (KQL jobs, notebook jobs) and write results to tables, including analytics tier tables | Security Operator, Security Administrator, Global Administrator |
For read-only access across the lake, Security Reader (or Global Reader) is the least-privileged choice. For scheduling jobs, Security Operator is the narrowest role that can. An Azure role such as Microsoft Sentinel Contributor manages the SIEM workspace but does not let someone schedule data lake jobs, and Azure roles such as Microsoft Sentinel Reader grant lake read only per workspace, one assignment each.
The three tiers: Analytics, Data Lake and XDR default
Each table's tier decides how its data can be used and what it costs: the Analytics tier is for data you detect and hunt on, the Data Lake tier is low-cost storage for data you only query occasionally, and the XDR default tier is the built-in advanced hunting window for Defender XDR data. XDR default-tier data isn't ingested into the Analytics or Data Lake tiers by default, so Sentinel analytics rules don't see it until you ingest the table. You manage tiers and retention per table on the Tables page in the Defender portal (Microsoft Sentinel > Configuration > Tables), using Manage table.
| Analytics tier | Data Lake tier | XDR default tier | |
|---|---|---|---|
| For | Detections, hunting, investigations, workbooks | Compliance, forensics, trend analysis | Defender XDR tables in advanced hunting |
| Retention | Analytics retention 30 days to 2 years; total retention up to 12 years (mirrored to the lake) | Total retention up to 12 years | 30 days in advanced hunting |
| Advanced hunting and Defender custom detections | Yes | No | Yes, within 30 days |
| Sentinel analytics rules and alerting | Yes | No | Only once the table is ingested into the Sentinel workspace (retention above 30 days, or the Defender XDR connector) |
| Reach the data with | KQL everywhere | KQL jobs, Spark jobs and notebooks, search jobs, summary rules | Advanced hunting |
Analytics retention and total retention are two settings. Analytics retention is the hot window with full query performance. Total retention is how long the data is kept in all; anything beyond the analytics window lives in the data lake at low cost and stays queryable from Sentinel through lake tools. To meet a long legal hold cheaply, keep the table in Analytics with the analytics retention the investigators need and set total retention to the legal period. Data kept this way stays raw and inside Sentinel; an aggregate (such as a summary rule's output) or a copy outside Sentinel answers a different requirement.
Choosing the Data Lake tier, and what stops working
Use the Data Lake tier for high-volume data that no detection needs, such as verbose flow or proxy logs kept for audits and later forensic look-backs: it has minimal ingestion cost and long retention. It is not free; the lake charges for ingestion, storage and processing (queries and jobs), just far less than the Analytics tier.
Moving a table from Analytics to Data Lake is a trade. Microsoft warns that alerting, advanced hunting, analytics rules and custom detection rules stop working against it. What keeps working:
- Search jobs over the table's data
- KQL jobs (one-off or scheduled) and Spark jobs and notebooks
- Summary rules that aggregate it into an Analytics table
So check which rules query a table before you move it.
Extending XDR data: 90-day analytics retention and Data Lake-only ingestion
Defender XDR tables such as DeviceProcessEvents are kept for 30 days in advanced hunting by default; to keep more, you change the table's retention in the Defender portal, which ingests it into your Sentinel workspace. The workspace must be onboarded to the Defender portal.
- Analytics retention up to 90 days: set analytics retention (and total retention) to 90 days. The data is ingested into the Analytics tier; Sentinel ingestion is charged, but storage for those 90 days is free. Hunting and detections get the full 90 days. Going beyond 90 days adds storage cost.
- Total retention longer than analytics retention: keep analytics at 30 days and set a longer total retention, and the older data is mirrored to the lake. Retention above 30 days still ingests the table into the Sentinel workspace, so this bills Sentinel ingestion plus data lake storage for the days beyond the analytics window.
- Data Lake-only ingestion: send the table only to the Data Lake tier with a long retention. The most recent 30 days still stay available in advanced hunting at no additional cost; the lake copy incurs ingestion, storage and processing charges. Advanced hunting and custom detections cover only those 30 days; older events are reached with lake tools.
To stop paying Sentinel ingestion for an XDR table, reset both analytics and total retention to the default 30 days. The table returns to the XDR default tier with its standard 30-day window. Microsoft warns that this reset disables the connector in the Azure portal, so review the connector afterwards.
What happens when you change retention
Changes behave differently depending on which setting moves and in which direction.
| Change | Effect |
|---|---|
| Shorten total retention | Microsoft waits 30 days before removing the data, so a mistake can be reverted by setting it back within that time |
| Lengthen total retention | Applies to existing data as well as new data |
| Change analytics retention | Applies at once. Example: at 180/180 days, lowering analytics retention to 90 moves data older than 90 days out of analytics retention immediately; the lake keeps it until day 180 |
So if someone mistakenly cuts total retention, set it back before the 30 days end; waiting longer loses the data, and leaving it unchanged means the older records are removed when the wait ends.
The Tables page and the permissions to change it
The Defender portal Tables page lists Sentinel tables, custom tables and Defender XDR tables, and lets you manage the tier and retention of most of them from one place. Three exceptions:
- Tables on the Basic Logs plan appear but are view-only for now; you manage them in the Log Analytics workspace. To manage one from the Defender portal, first change its plan from Basic Logs to Analytics in the workspace.
- Some tables in the XDR default tier aren't supported (Microsoft's example is IdentityInfo): you can view them, but you can't manage them from the Defender portal.
- Tier changes aren't available for every table: some Defender XDR and Sentinel solution tables must stay in the Analytics tier.
Saving on Manage table needs table write permissions. Per workspace, that is an Azure role with Microsoft.OperationalInsights/workspaces/write and workspaces/tables/write, such as Log Analytics Contributor. Alternatively, a Microsoft Defender XDR unified RBAC role with Data (manage) permission works, but it applies across all Sentinel workspaces. Microsoft Sentinel Contributor on its own manages Sentinel content but not these table settings; Microsoft's Table insights permissions list Microsoft Sentinel Contributor and Log Analytics Contributor at workspace scope as the minimum to change a tier or retention there, so Log Analytics Contributor is the role added on top. Log Analytics Reader only reads.
Creating and configuring Microsoft Sentinel workbooks
Microsoft Sentinel workbooks are Azure Monitor workbooks for visualizing Sentinel data; you start from a template installed from the Content hub or build one from scratch with Add workbook.
Templates and saved workbooks
The Templates tab shows only templates you have installed. Microsoft's workbooks ship inside Content hub solutions (for example, the Microsoft Entra ID solution contains the Microsoft Entra ID Sign-in logs workbook) or as standalone Content hub items, so if a template is missing, install its solution. Selecting Save on a template creates a new workbook resource in the location you choose. Only the workbook's JSON definition is stored, never query results. Then View saved workbook and Edit to customize it. The template itself is unchanged and stays on the Templates tab; deleting the saved copy leaves it available.
Query steps
To query Sentinel tables, set the step's Data source to Logs and Resource type to Log Analytics, then choose one or more workspaces; one step can query several workspaces. Other data sources (Azure Resource Graph, Metrics) and resource types (Application Insights) read other data. Queries can use ASIM parsers so one visual works across sources that normalize to the same schema. Parameters such as a TimeRange change the lookback, not how often data updates.
Refresh and export
Auto refresh in the toolbar reruns the workbook's queries on an interval from 5 minutes to 1 day; it pauses while editing and stops when the workbook closes. Print and Save as PDF are available only in the Azure portal: in the Defender portal, select Open in Azure and use Print content. (Microsoft has said Sentinel's Azure portal experience retires after 31 March 2027, so this route may change.)
SOC optimization: data value, coverage and similar organizations recommendations, and their status
SOC optimization is a Microsoft Sentinel page that recommends actions to cut cost and close detection gaps, calculated from your own workspace and refreshed every 24 hours. Recommendations fall into three types: data value, coverage-based (threat-based, risk-based and AI MITRE ATT&CK tagging) and similar organizations.
| Recommendation | What it looks at | Typical actions |
|---|---|---|
| Data value | Billable tables that ingested data in the last 30 days but weren't used by analytics rules or detections | Turn on rule templates that use the table, move it to a cheaper tier or plan, stop ingesting it |
| Threat-based coverage | Your logs and active rules against what a threat scenario (for example, human-operated ransomware) needs | Turn on recommended analytics rule templates (Go to Content hub); connect data sources that active detections lack |
| Risk-based coverage (preview) | Coverage of business risk scenarios relevant to your organization | Add detections and data sources for those risks |
| AI MITRE ATT&CK tagging, a coverage type (preview) | Detections with no tactics or techniques; an AI model on your workspace proposes tags | Apply to one analytics rule, to all rules, or to none |
| Similar organizations (its own type) | Tables that organizations with similar ingestion trends and industry profiles collect and you don't | Consider ingesting those sources |
Data value exemptions: SOC optimization doesn't recommend ingestion changes for tables chosen for User and Entity Behavior Analytics (UEBA) or used by a threat intelligence matching analytics rule, so such a table gets no recommendation even when no other rule uses it. Table insights on the Tables page is a different view: it shows a table's volume and cost, not whether detections use it.
Similar organizations recommendations rely only on organizational information and system metadata; Microsoft states the models never access or analyze the content of customer logs. Newer SOCs are more likely to see them. The MITRE ATT&CK page only displays coverage from existing tags; it doesn't propose new ones.
Managing optimization status
Every optimization has a status: Active, In progress, Completed or Dismissed, and you change it to reflect what the SOC is doing about it.
- Active: the starting state, on the Overview list.
- In progress: someone is working on it (you can set it back to Active).
- Completed: every recommended action has been taken. Sentinel also completes an optimization automatically when a change makes it irrelevant; Microsoft's example is a previously unused table that a new analytics rule now queries.
- Dismissed: you won't act on it. It leaves the Overview list and sits on the Dismissed tab.
From the Completed or Dismissed tab you can reactivate an optimization. It is recalculated to show current value and actions, which can take up to an hour, and it may move straight to Completed if it is no longer relevant. You can also give feedback on a recommendation, which doesn't change its status.
Tip. Questions on this topic describe a SOC team, its Sentinel workspace and a requirement, then ask which role, scope, tier, retention setting, workbook option or SOC optimization feature meets it. Requirements usually combine a functional need with a constraint such as least privilege, scope, cost or continued access to the data, so the answer depends on knowing exactly what each role, tier and setting does and doesn't cover. Some items describe a symptom or an unexpected result and ask for the cause or the fix, and some ask you to select two statements that describe the result of a change.
- Sentinel roles are cumulative: Reader views, Responder adds incident management, Contributor adds creating content and installing Content hub solutions.
- Reader or Responder plus Workbook Contributor lets someone save workbooks without other write rights; guests who assign incidents also need Entra Directory Readers.
- Assign Sentinel roles on the workspace's resource group; at resource scope, assign both the workspace and its SecurityInsights solution. Extra assignments never subtract rights.
- Data lake access comes from Entra roles: Security Reader to read across all workspaces, Security Operator to create jobs and write to tables.
- Analytics retention (30 days to 2 years) is the hot window; total retention (up to 12 years) keeps older data cheaply in the lake, still queryable from Sentinel.
- The Data Lake tier stops analytics rules, alerting, advanced hunting and custom detections; search jobs, KQL and Spark jobs and summary rules still work.
- XDR tables: 30 days by default; up to 90 days of analytics retention charges ingestion but not storage; resetting to 30/30 stops Sentinel ingestion.
- Shortening total retention waits 30 days before deleting; analytics retention changes apply immediately.
- Workbook templates come from Content hub solutions; Save creates a JSON-only workbook you edit; print and PDF need Open in Azure.
- SOC optimization: data value flags billable tables unused by detections in 30 days (UEBA and TI matching tables exempt); dismiss what you won't act on.
Frequently asked questions
What is the difference between Microsoft Sentinel Reader, Responder and Contributor?
The three roles are cumulative. Microsoft Sentinel Reader can view data, incidents, workbooks and rules. Responder adds incident management such as assigning owners, changing status and adding comments. Contributor adds creating and editing workbooks, analytics rules and other Sentinel resources, and installing or updating Content hub solutions.
Which role lets a Sentinel Reader create workbooks?
Add the Azure Workbook Contributor role. Microsoft Sentinel Reader and Responder can view workbooks but can't create or save them; Workbook Contributor adds that without granting incident or analytics rule rights, which Microsoft Sentinel Contributor would.
Why can't a guest user assign Microsoft Sentinel incidents?
Assigning an owner reads users from Microsoft Entra ID, and B2B guests can't read the directory by default. Grant the guest the Microsoft Entra Directory Readers role in addition to Microsoft Sentinel Responder.
What is the difference between analytics retention and total retention in Microsoft Sentinel?
Analytics retention is how long a table's data stays in the Analytics tier with full query performance for rules and hunting, from 30 days to two years. Total retention is how long the data is kept in all, up to 12 years; data older than the analytics window is kept in the Microsoft Sentinel data lake at low cost and can be queried with KQL jobs, notebooks and search jobs.
What stops working when a table moves to the Data Lake tier?
Alerting, advanced hunting, analytics rules and custom detection rules no longer work against the table. Its data remains reachable through search jobs, KQL and Spark jobs, notebooks and summary rules, at a much lower ingestion cost.
How do you keep Defender XDR data longer than 30 days?
In the Defender portal, raise the table's retention on the Tables page; the data is then ingested into the Sentinel workspace. Analytics retention up to 90 days charges Sentinel ingestion but not storage, and you can also send the table only to the Data Lake tier for a long, cheaper record while the latest 30 days stay in advanced hunting. Resetting retention to 30 days stops the ingestion.
Can you undo a shortened total retention in Microsoft Sentinel?
Yes, within 30 days. When total retention is shortened, Microsoft waits 30 days before removing the data, so setting it back within that time keeps the older records. Analytics retention changes, by contrast, take effect immediately.
What are SOC optimization recommendations in Microsoft Sentinel?
They are recommendations calculated every 24 hours from your workspace. Data value recommendations flag billable tables that detections haven't used in the last 30 days; coverage recommendations (threat-based, risk-based and AI MITRE ATT&CK tagging) suggest rule templates, data sources and tags to close gaps; and similar organizations recommendations, a third type, suggest data sources that organizations like yours ingest. Each can be marked in progress, completed or dismissed, and reactivated later.
Source
This lesson covers the "Manage a security operations environment" domain of the official SC-200 exam guide. Vendors revise their guides — check the source for the current version.
- Microsoft SC-200 study guide — Microsoft Learn
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.