Sentinel Workspace: Roles & Retention

What is a Microsoft Sentinel workspace?

Microsoft Sentinel roles

Not everyone in a SOC needs the same access. Sentinel uses Azure RBAC (role-based access control) to separate duties.

Role	What They Can Do	Who Gets It
Microsoft Sentinel Reader	View incidents, workbooks, hunting queries, and data — but cannot change anything	Junior analysts, auditors, stakeholders
Microsoft Sentinel Responder	Everything a Reader can do, plus manage incidents (assign, change status, add comments)	Tier 1 and Tier 2 analysts
Microsoft Sentinel Contributor	Everything a Responder can do, plus create/edit workbooks, analytics rules, and automation	Senior analysts, detection engineers
Microsoft Sentinel Playbook Operator	Run playbooks manually on incidents	Analysts who need to trigger automation
Logic App Contributor	Create and edit playbooks (Logic Apps)	Automation engineers

💡 Scenario: Anika's MSSP role structure

Anika Singh manages Sentinel for 40+ clients at Sentinel Shield (MSSP). She cannot give every client’s analysts Contributor access — they might accidentally edit another client’s analytics rules.

Her role design:

• Client analysts → Sentinel Responder (manage their own incidents, cannot edit rules)
• Sentinel Shield Tier 2 → Sentinel Contributor (edit analytics rules across workspaces)
• Automation team (Dev) → Logic App Contributor + Playbook Operator (build and test playbooks)
• Client CISOs → Sentinel Reader (dashboards and reports only)

Each client workspace uses resource-level RBAC so analysts only see their own data.

💡 Exam tip: role hierarchy

The exam loves testing whether you know the hierarchy: Reader → Responder → Contributor. Each level includes everything below it.

Key distinction: Responder can manage incidents but cannot create analytics rules. If a question says “an analyst needs to create a scheduled rule,” the answer is Contributor, not Responder.

Also remember: Playbook Operator is separate from the main hierarchy. A Responder cannot run playbooks unless they also have Playbook Operator.

Data retention: Analytics, Data lake, and XDR tiers

Where your data lives determines how fast you can query it and how much it costs.

Choose the right tier based on how often you query the data and how long you need to keep it

Feature	Analytics Tier	Data Lake Tier	XDR Tier
Purpose	Hot data for active investigation and detection	Long-term, cost-effective storage for compliance and hunting	Microsoft Defender XDR data at no extra Sentinel cost
Query speed	Fastest — optimised for KQL	Slower — designed for occasional queries	Fast — pre-ingested by Defender
Cost	Highest per GB	Significantly cheaper	Included with Defender XDR licence
Retention	Default 30 days (Sentinel solution tables get free extension to 90 days), configurable up to 2 years	Up to 12 years	Default 30 days in Defender, extends with Sentinel
Use case	Active alerts, real-time detection, incident investigation	Audit logs, historical hunting, compliance requirements	Defender incidents, alerts, device events
Analytics rules	Yes — scheduled, NRT, ML all work	Limited — summary rules for aggregated queries	Yes — included in unified Sentinel experience

How to decide which tier

1. High-frequency data you query daily (security events, sign-in logs, firewall logs) → Analytics tier
2. Compliance or audit data you rarely query (Azure activity logs older than 90 days, historical DNS) → Data lake tier
3. Defender XDR data (incidents, alerts, device events from MDE/MDO/MDI/MDCA) → XDR tier (already there)

💡 Scenario: James optimises Pacific Meridian's costs

James Mwangi at Pacific Meridian (10,000 staff) was spending $45,000/month on Sentinel ingestion. His team ran a cost analysis:

• 70% of queries hit the last 30 days of data
• Compliance requirement: keep Azure AD sign-in logs for 7 years
• Defender XDR data was being double-ingested into Analytics tier

James moved:

• Historical sign-in logs → Data lake (7-year retention, much cheaper)
• Defender data → XDR tier (already included, stopped duplicate ingestion)
• Kept active security events in Analytics (30-day default retention, extended to 90 days for Sentinel solution tables)

Result: 38% cost reduction while meeting compliance requirements.

Workbooks: your SOC dashboards

Workbooks are interactive dashboards in Sentinel that visualise your security data. They combine KQL queries, charts, tables, and parameters into reusable reports.

Common workbook types:

• Incident overview — open incidents by severity, mean time to resolve, analyst workload
• Data connector health — which connectors are active, which have stopped sending data
• Threat intelligence — indicator counts, types, sources, expiration dates
• Investigation — entity timelines, related alerts, geographic maps

You can use built-in workbook templates from the Content Hub or create custom workbooks from scratch.

💡 Exam tip: workbooks vs analytics rules

Workbooks visualise data. Analytics rules detect threats. The exam may describe a scenario where someone wants a “dashboard showing failed sign-ins” — that’s a workbook. If they want an “alert when failed sign-ins exceed 50 in 5 minutes” — that’s an analytics rule.

SOC optimization

Microsoft Sentinel includes SOC optimization recommendations — built-in analysis of your workspace configuration that suggests improvements.

SOC optimization checks for:

• Coverage gaps — MITRE ATT&CK techniques not covered by your analytics rules
• Data value — tables ingesting data that no analytics rule or workbook references
• Cost efficiency — tables that could move to a cheaper tier without impacting detection
• Threat intelligence — whether your TI feeds are active and being used in detections

Think of it as a health check for your SOC — it tells you what you are missing, what you are wasting money on, and where to focus next.

Question

What are the three data retention tiers in Microsoft Sentinel?

Click or press Enter to reveal answer

Answer

1. Analytics tier — hot data for active detection and investigation (fastest, most expensive, default 30 days — Sentinel solution tables get free extension to 90 days). 2. Data lake tier — long-term, cost-effective storage for compliance and historical hunting (up to 12 years). 3. XDR tier — Defender XDR data included at no extra Sentinel cost.

Click to flip back

Question

A Sentinel Responder wants to create a new scheduled analytics rule. Can they?

Click or press Enter to reveal answer

Answer

No. Sentinel Responder can manage incidents (assign, change status, comment) but cannot create or edit analytics rules. They need the Sentinel Contributor role for that.

Click to flip back

Question

What does SOC optimization in Microsoft Sentinel analyse?

Click or press Enter to reveal answer

Answer

SOC optimization checks for: coverage gaps (MITRE ATT&CK techniques without detection rules), data value (tables not referenced by rules or workbooks), cost efficiency (tables that could move to cheaper tiers), and threat intelligence health (whether TI feeds are active and used).

Click to flip back

Knowledge Check

Anika at Sentinel Shield needs a client's junior analyst to view incidents and dashboards but not change anything. Which role should she assign?

AMicrosoft Sentinel ContributorBMicrosoft Sentinel Playbook OperatorCMicrosoft Sentinel ReaderDMicrosoft Sentinel Responder

Check Answer

Knowledge Check

James at Pacific Meridian needs to keep Entra ID sign-in logs for 7 years to meet compliance. Which Sentinel data tier should he use for the historical data?

AAnalytics tier with 7-year retentionBData lake tier with 7-year retentionCXDR tier — sign-in logs come from EntraDArchive the logs to Azure Blob Storage instead

Check Answer

Knowledge Check

Pacific Meridian's SOC optimization recommends moving SecurityEvent data to the Data lake tier. James checks: no analytics rules reference SecurityEvent, but his threat hunter Tyler uses it daily for KQL hunting. What should James do?

AMove it to Data lake immediately — SOC optimization is always correctBKeep it in Analytics tier — if anyone queries it, it should stay hotCMove it to Data lake but create a summary rule to pre-aggregate key security events for Tyler's common hunting patternsDDelete the SecurityEvent table to save costs

Check Answer

🎬 Video coming soon

Next up: Now that the workspace is ready, it’s time to get data flowing in. We’ll start with the most common source — Windows security events.