SC-200: Microsoft Security Operations Analyst Study Guide
The SC-200: Microsoft Security Operations Analyst exam validates your ability to run a security operations center using Microsoft Sentinel, Microsoft Defender XDR, and Microsoft Defender for Cloud. It targets SOC analysts who configure protections and detections, triage and respond to incidents, and proactively hunt threats across Microsoft's security stack. Expect 685-style scenario questions covering workspace design, KQL, analytics rules, automation, and the unified Defender portal experience, with a passing score of 700 over 120 minutes.
Domain 1: Manage a Security Operations Environment
- Microsoft's recommended Sentinel architecture for multi-subscription, multi-region tenants is a single centralized Log Analytics workspace with Sentinel enabled, simplifying cross-source correlation, RBAC, and analytics.
- Sentinel built-in roles are Reader, Responder (triage/manage incidents and run playbooks), and Contributor (create/edit rules and content); assign the least-privilege role plus Log Analytics roles as needed.
- Retention can be set per table to override the workspace default - for example setting SecurityEvent to 180 days extends only that table without raising cost on every other table.
- The long-term retention (archive) tier stores data cheaply beyond the interactive retention period; you run search jobs or restore archived data to query it.
- The Content Hub is the centralized marketplace for packaged solutions that bundle data connectors, analytics rules, workbooks, hunting queries, and playbooks, deployable in a single action.
- Threat indicators are imported via purpose-built connectors: Microsoft Defender Threat Intelligence (curated Microsoft IOCs) and Threat Intelligence - TAXII (connect to a TAXII 2.x server), landing in the ThreatIntelligenceIndicator table.
- You can add indicators manually through the Threat Intelligence blade or programmatically via the Upload Indicators API (the modern replacement for the deprecated tiTaxiiClient/Graph Security API path).
- Watchlists import structured CSV reference data (known-bad IPs, VIP accounts, approved domains) into a searchable list referenced in KQL via the _GetWatchlist() function to enrich alerts and incidents.
- CEF and Syslog from network appliances are collected by a Linux log forwarder running the Azure Monitor Agent (AMA) with a Data Collection Rule (DCR); the legacy OMS/rsyslog path is being retired in favor of AMA.
- Windows event collection uses the Azure Monitor Agent (AMA) with DCRs; the older Microsoft Monitoring Agent (MMA/Log Analytics agent) is deprecated.
- Choosing the 'Common' event set in the Windows Security Events connector ingests a reduced, high-value subset of events versus 'All Events', reducing ingestion cost.
- Microsoft Defender XDR data tables ingest free of charge into Sentinel when piped through the Defender XDR connector; Microsoft 365 connectors (Office 365, SharePoint, Exchange) carry no premium licensing beyond standard Log Analytics ingestion pricing.
- The unified security operations platform is enabled in the Microsoft Defender portal and surfaces both Defender XDR and Sentinel incidents and alerts in one interface, eliminating portal switching.
- Sentinel repositories (CI/CD via 'Repositories') connect to Azure DevOps or GitHub to deploy analytics rules and content as code; data residency requirements are met by choosing the workspace's Azure region carefully.
Domain 2: Configure Protections and Detections
- Scheduled query analytics rules run on a configurable frequency (as short as every 5 minutes) over a lookback window and aggregate with KQL - the right choice for threshold-based detections like brute-force sign-in counts.
- Near-real-time (NRT) analytics rules run automatically once per minute with a fixed one-minute lookback (querying on ingestion time to absorb data-source delay); they are limited to a single query with no scheduling flexibility but minimize detection latency.
- Microsoft Sentinel includes ML-driven anomaly rule templates (impossible travel, unusual data transfer, anomalous sign-ins) that detect outliers without manual query authoring.
- Fusion correlates alerts from multiple data sources into multi-stage attack incidents using machine learning; it is enabled by default and surfaces high-fidelity advanced threats.
- Microsoft Defender for Identity monitors Active Directory authentication (Kerberos and NTLM) to detect lateral movement such as Pass-the-Hash and Pass-the-Ticket; sensors install on domain controllers (or a standalone sensor with port mirroring).
- A honeytoken account is tagged in Defender for Identity settings; any authentication activity against it is suspicious by design and raises an alert.
- Microsoft Defender for Endpoint custom detection rules are built from advanced hunting KQL and can trigger automated response actions such as Isolate device, Collect investigation package, or Run AV scan.
- Microsoft Defender XDR custom detection rules are authored in the Defender portal using KQL across the unified advanced hunting schema (DeviceProcessEvents, EmailEvents, IdentityLogonEvents, etc.).
- Attack Surface Reduction (ASR) rules should be deployed in audit mode first to measure impact, then switched to block mode to avoid breaking legitimate workflows.
- Defender for Office 365 Safe Links provides time-of-click URL rewriting and reputation checks; Safe Attachments detonates attachments in a sandbox and can use Dynamic Delivery (replace attachment with a placeholder and deliver the body immediately).
- Microsoft Defender for Cloud Apps discovers shadow IT via Cloud Discovery (firewall/proxy logs) and endpoint-based discovery (Defender for Endpoint network signals); session policies with content inspection enforce real-time controls via reverse proxy.
- Microsoft Defender for SQL detects SQL injection, anomalous database access, and vulnerabilities on Azure SQL and SQL on VMs; web content filtering relies on network protection being enabled in Defender for Endpoint.
- Alert grouping with entity matching (for example on IP address) in incident settings consolidates related alerts into a single incident to reduce noise.
- Automated Investigation and Response (AIR) is configured in the Defender XDR security policy and automatically investigates alerts, determines verdicts, and can auto-remediate based on the automation level set.
Domain 3: Manage Incident Response
- The Sentinel Investigation Graph visually maps an incident's entities (users, hosts, IPs, files) and the alerts connecting them, letting analysts expand related entities to scope an attack quickly.
- Automation rules evaluate incident properties (severity, MITRE tactic, title) at creation or update and can assign owners, change severity, add tags, close incidents, or run playbooks.
- Within an automation rule, actions execute sequentially in the order they are defined; ordering matters when one action depends on a prior one.
- Playbooks are Azure Logic Apps; the Microsoft Sentinel incident trigger runs them on incident events, the entity trigger runs them on a specific entity, and connectors (Teams, email, ServiceNow) perform the response actions.
- A playbook's Logic App managed identity must hold the Microsoft Sentinel Responder role on the resource group (or workspace) to update incidents it acts on.
- Defender for Endpoint 'Isolate device' cuts network connectivity while preserving the Defender service channel so the analyst can still investigate and run live response.
- The 'Collect investigation package' action in Defender for Endpoint gathers forensic artifacts (event logs, temp files, network config, autoruns) from a compromised device for offline analysis.
- Compromised-account containment in Entra ID uses two actions: revoke sessions (require sign-in again) and disable the user (suspend from signing in); both are exposed as Sentinel/Defender response actions.
- Closing an incident requires a classification - True Positive, Benign Positive, False Positive, or Undetermined - plus a closing comment for audit and tuning of UEBA and rules.
- UEBA entity pages provide a consolidated timeline, peer comparison, and a calculated investigation priority/risk score for each user, host, and IP over a chosen window.
- Correlating successful sign-ins from IPs that previously failed uses a KQL join (typically kind=inner) between SigninLogs failures and successes on the IPAddress column.
- Advanced hunting tables such as DeviceProcessEvents and DeviceFileEvents are queried in the Defender portal to scope process execution and file activity during an investigation.
- Sentinel cannot manually attach individual alerts from different analytics rules onto an existing incident from the incident actions menu; grouping is governed by rule alert-grouping settings.
- Microsoft incident-creation rules let the Defender for Cloud (and other Microsoft) connectors automatically create Sentinel incidents from provider alerts.
Domain 4: Perform Threat Hunting
- Livestream runs a KQL query continuously and notifies you when results appear, without creating alerts or incidents - ideal for watching an active hunt or emerging campaign in real time.
- Hunting bookmarks preserve interesting query results along with the query and analyst notes; bookmarks can be promoted to incidents or added to existing ones.
- Promising hunting queries can be operationalized by promoting them to a scheduled analytics rule, or to an NRT rule when low detection latency is required.
- The MITRE ATT&CK blade maps active analytics rules and hunting queries to tactics and techniques, visualizing detection coverage and highlighting gaps.
- Threat Intelligence matching analytics rules automatically correlate ThreatIntelligenceIndicator entries against log tables to surface IOC hits; you can also manually join the TI table with log tables.
- Sentinel Jupyter notebooks run on Azure Machine Learning compute instances linked to the workspace, using MSTICPy and Sentinel APIs for advanced Python-based analysis.
- series_decompose_anomalies() detects statistically anomalous points in a time series; build the series first with make-series, then apply the function to flag spikes such as unusual data transfer volumes.
- Encoded/obfuscated PowerShell is hunted by querying DeviceProcessEvents for ProcessCommandLine containing '-EncodedCommand' or '-enc'.
- Credential-theft against LSASS is hunted in DeviceEvents by filtering ActionType for values like 'OpenProcessApiCall' on lsass.exe or actions containing 'LsassAccess'.
- Command-and-control beaconing is hunted in DeviceNetworkEvents by filtering for known C2 domains, and DNS exfiltration by flagging unusually long subdomain labels and high query volumes per host.
- Data exfiltration volume is profiled by querying DeviceNetworkEvents and using summarize to total bytes sent per device, then filtering against a baseline threshold.
- Geo-enrichment of an IpAddress entity uses the built-in GeoIP lookup provider to attach location context to hunting results.
- Custom hunting queries are saved and managed on the Sentinel Hunting page (Hunting blade), where they can be run against current data and grouped by MITRE technique.
- Advanced hunting in Defender XDR uses the unified schema (DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, EmailEvents, IdentityLogonEvents) and supports a 30-day raw data lookback.
SC-200 exam tips
- Know exactly which analytics rule type fits a scenario: Scheduled for aggregated thresholds, NRT for ~1-minute low-latency single-query detection, Microsoft incident-creation for provider alerts, and anomaly/Fusion for ML-driven detection.
- Memorize the Defender for Endpoint response actions and what each preserves: Isolate device (keeps Defender connectivity), Collect investigation package (forensics), Run AV scan, and Restrict app execution.
- Practice reading KQL: recognize join, summarize, make-series with series_decompose_anomalies(), project, and the common advanced hunting table names - questions hinge on picking the right table and operator.
- Distinguish the Microsoft security products by what data they protect: Defender for Identity (on-prem AD/Kerberos/NTLM), Defender for Cloud Apps (SaaS/shadow IT), Defender for Office 365 (email/Safe Links/Safe Attachments), Defender for Endpoint (devices).
- Watch for cost and architecture cues - single centralized workspace, per-table retention, archive tier, 'Common' vs 'All Events', and AMA-with-DCR over the deprecated MMA - these phrases signal the intended answer.
Study guide FAQ
How is SC-200 structured and what score do I need to pass?
The exam is scored 1-1000 with 700 to pass, runs 120 minutes, and covers four weighted domains: Manage a security operations environment, Configure protections and detections, Manage incident response, and Perform threat hunting. Expect scenario-based multiple choice, multiple-response, and case studies, often including KQL snippets you must interpret.
Which products and skills should I focus on most?
Microsoft Sentinel and Microsoft Defender XDR dominate the exam, so prioritize Sentinel analytics rules, automation rules and playbooks, data connectors, and the unified Defender portal. Be fluent in KQL for both Sentinel and advanced hunting, and know the role each Defender plan plays (Identity, Endpoint, Office 365, Cloud Apps, Cloud, SQL).
How much KQL do I really need to know?
Enough to read and choose the correct query, not write production code from scratch. Be comfortable with where/project/summarize/join/make-series, the series_decompose_anomalies() function, and the names of common advanced hunting tables such as DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, SigninLogs, and ThreatIntelligenceIndicator.
What changes from the unified security operations platform should I expect?
Microsoft has consolidated Sentinel into the Microsoft Defender portal, so incidents and alerts from both Sentinel and Defender XDR appear in one place. Expect questions about enabling this unified platform, free Defender XDR data ingestion, the Azure Monitor Agent replacing the legacy MMA, and the Upload Indicators API replacing older threat-intelligence ingestion methods.