7.13 Module Summary

Module 7 Summary: Configure Your Microsoft Sentinel Environment

What you learned in this module

This module built the Sentinel foundation that every subsequent module depends on. Without a properly configured workspace, analytics rules have no data to evaluate, hunting queries have no logs to search, and automation playbooks have no incidents to respond to. The decisions you made here — workspace architecture, log tier assignments, retention policies, RBAC model — determine the capabilities, cost, and effectiveness of Modules 8-10.

Subsection 7.1 — SIEM + SOAR Architecture. Sentinel’s five core functions (collect, store, detect, investigate, respond), the cloud-native advantage over traditional SIEM, the Log Analytics workspace foundation, the SOAR component (automation rules + playbooks), and the end-to-end data flow from ingestion to automated response.

Subsection 7.2 — Workspace Architecture. The single-workspace default recommendation, when multi-workspace is justified (data residency, MSSP, regulatory requirements), the RBAC approach within a single workspace, the MSSP model with Azure Lighthouse, and workspace naming conventions.

Subsection 7.3 — Creating and Configuring. Step-by-step workspace deployment, pricing tier selection (pay-as-you-go vs commitment tiers), the free 5 GB/day tier, diagnostic settings, health monitoring enablement, and the post-deployment verification checklist. The critical lesson: never set a daily cap in production.

Subsection 7.4 — Log Types and Tiers. The three-tier model: Analytics (full capability, highest cost), Basic (limited KQL, no analytics rules, ~60% cheaper), Archive (storage only, compliance retention). Which tables must stay on Analytics (SigninLogs, SecurityAlert, DeviceProcessEvents) and which can safely move to Basic (AzureMetrics, ContainerLog). The XDR tier and Auxiliary logs for emerging data classification.

Subsection 7.5 — Data Retention and Cost Management. Workspace default and per-table retention policies, cost estimation and monitoring with the Usage table, five ingestion optimisation techniques (collection level, transformation at ingestion, commitment tiers, M365 E5 data grant, Basic tier assignment), cost reporting for management using cost-per-incident metrics, and the danger of daily caps as a cost control mechanism.

Subsection 7.6 — Key Tables and Schema. The 20 tables SOC analysts query most frequently, organised by domain: identity (SigninLogs, AuditLogs), endpoint (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceLogonEvents), email (EmailEvents, EmailAttachmentInfo, UrlClickEvents), cloud (CloudAppEvents, OfficeActivity, AzureActivity), security (SecurityAlert, SecurityIncident), and infrastructure (Syslog, CommonSecurityLog, Heartbeat, ThreatIntelligenceIndicator). The cross-product join map that connects tables for cross-domain investigation.

Subsection 7.7 — Watchlists. Creating named datasets from CSV files, referencing watchlists in KQL with _GetWatchlist(), common SOC patterns (VIP users, approved IPs, high-value assets, departing employees, TI allowlists), watchlist lifecycle management, and the advantage of dynamic watchlists over hardcoded values.

Subsection 7.8 — Threat Intelligence. Indicator types (IP, domain, URL, file hash, email), ingestion sources (MDTI, STIX/TAXII feeds, TIP integration, manual entry), the ThreatIntelligenceIndicator table, TI matching analytics rules, indicator lifecycle management (expiration, confidence scoring, deduplication), and operational TI patterns (automatic enrichment, retroactive hunting, investigation enrichment).

Subsection 7.9 — Integrating Defender XDR. The unified security operations platform, the Defender XDR data connector with bi-directional incident sync, the XDR tier for cost-free Defender data ingestion, unified Advanced Hunting across both platforms, and the operational model (investigation in Defender portal, configuration in Azure portal).

Subsection 7.10 — Content Hub and Solutions. Deploying pre-built analytics rules, workbooks, playbooks, and hunting queries from Content Hub. The critical distinction between rule templates (deployed by solutions) and active rules (created by analysts after review). Solution quality evaluation, update management, and the essential solutions for M365 environments.

Subsection 7.11 — Workspace Health. The SentinelHealth table, data ingestion monitoring (volume tracking, zero-ingestion detection), analytics rule execution monitoring, and the operational health dashboard — the SOC team’s shift-start flight check that catches health issues before they affect investigation capability.

Subsection 7.12 — RBAC and Governance. The four Sentinel roles (Reader, Responder, Contributor, Playbook Operator), workspace-level roles, table-level and resource-context RBAC, multi-workspace governance with Sentinel-as-code and CI/CD, Azure Lighthouse for MSSPs, and the governance framework (change control, naming conventions, severity criteria, ATT&CK mapping, quarterly access review, audit trail).

SC-200 exam objectives covered

Domain 1 — Manage a Security Operations Environment (40-45%): Design and configure a Microsoft Sentinel workspace. Manage data retention for XDR and Sentinel tables. Query logs in Microsoft Sentinel. Use watchlists. Utilize threat intelligence. Integrate Defender XDR with Sentinel.

This module covers the largest SC-200 exam domain. The concepts — workspace architecture, log tiers, retention, RBAC, TI integration, Content Hub, and the unified platform — appear in approximately 20-25% of all exam questions.

What comes next

Module 8 — Connect Logs to Sentinel. Fill the workspace with data: Microsoft connectors, Syslog/CEF, custom tables, data collection rules, and connector troubleshooting.

Module 9 — Create Detections and Perform Investigations. Build analytics rules and automation that turn raw data into actionable security incidents.

Module 10 — Threat Hunting in Sentinel. Proactive threat hunting using the data, tables, and TI you configured in this module.

Together, Modules 7-10 complete the Sentinel operational capability — from workspace creation through data ingestion, detection, and proactive hunting.

Skills checklist

Before moving to Module 8, verify you can perform each of these tasks:

Architecture and deployment. Explain the relationship between Log Analytics workspace and Sentinel. Decide between single and multi-workspace architecture for a given scenario. Create a workspace with the correct region, pricing tier, and retention settings. Enable Sentinel and configure diagnostic settings and health monitoring. Explain why daily caps should never be set in production.

Data management. Describe the three log tiers (Analytics, Basic, Archive) and their capability trade-offs. Select the correct tier for a given table based on investigation value and cost. Configure per-table retention policies to meet both investigation and compliance requirements. Estimate monthly Sentinel cost from daily ingestion volume. Apply at least three cost optimisation techniques (collection level, DCR transformation, commitment tier, Basic tier assignment, M365 E5 data grant).

Tables and queries. Identify the 20 key security tables and the data each contains. Name the key columns for SigninLogs, DeviceProcessEvents, EmailEvents, CloudAppEvents, SecurityAlert, and AzureActivity. Write a cross-product join query that correlates identity data with endpoint or application data. Use the cross-product join map to trace an attack chain across multiple tables.

Enrichment and intelligence. Create a watchlist from a CSV file and reference it in KQL with _GetWatchlist(). Write a KQL query that uses a watchlist for enrichment (VIP escalation) and exclusion (approved IP filtering). Ingest threat intelligence from at least one source (manual entry, MDTI, or STIX/TAXII). Enable TI-matching analytics rules for your active data sources.

Integration and operations. Explain the unified security operations platform (Sentinel + Defender XDR). Configure the Defender XDR data connector with bi-directional incident sync. Deploy a Content Hub solution and create active rules from templates. Monitor workspace health using SentinelHealth and Usage tables. Describe the four Sentinel RBAC roles and assign the correct role for each SOC team function.

Key decisions recap

These are the decisions you made (or will make) during this module that have lasting impact:

Workspace architecture — single vs multi-workspace. Default: single workspace + RBAC. Multi-workspace only for data residency, MSSP, or strict regulatory requirements.

Log tier assignment — Analytics for investigation and detection tables. Basic for high-volume, low-security-value tables. Archive for compliance retention beyond the Analytics period.

Retention policy — 90 days Analytics (included free) for active investigation. Per-table extensions for long-running investigation needs. Archive for compliance periods (1-7 years).

Cost model — pay-as-you-go for lab and small deployments. Commitment tier at minimum consistent daily volume for 100+ GB/day environments.

RBAC model — Reader for managers, Responder for Tier 1, Contributor for Tier 2/3 and detection engineers. Table-level RBAC for sensitive data segregation within a single workspace.

Governance model — Sentinel-as-code with CI/CD for multi-analyst teams. Naming conventions, severity criteria, MITRE mapping, and quarterly access review as the governance baseline. Start with the governance level appropriate for your current team size, and scale the framework as the team grows — informal coordination for 2 analysts, formal CI/CD and change control for 5 or more.