How to pass Microsoft Security Operations Analyst (SC-200)

How this exam thinks

What each domain tests and how to study it

The SC-200 blueprint is split across 3 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.

1. Manage a Security Operations Environment

   41% of exam

   What you must be able to do. Choose and configure the correct Microsoft Sentinel or Microsoft Defender XDR detection, automation, data-ingestion, role, or platform mechanism that meets a stated operations requirement with the least administrative effort.

   In one sentenceThe backbone layer: analytics and custom detection rules, automation rules and playbooks, ASR and Defender for Endpoint features, data connectors and ingestion, roles, retention, and ATT&CK mapping.

   Recall check: answer these from memory first

   • Which attack surface reduction rule mode lets the action proceed while logging a DeviceEvents entry so you can measure impact for two weeks before enforcing?
   • What two outputs must an Advanced Hunting query return before it can be saved as a Microsoft Defender XDR custom detection rule?
   • Which approach streams resource diagnostic logs to the Microsoft Sentinel workspace across current and future resources with the least ongoing effort?
   • Which built-in Microsoft Sentinel role is the least privilege that can author and tune analytics rules and workbooks at workspace scope?

   What it tests. Whether you can stand up and tune the detection and automation backbone of the SOC: configuring Microsoft Defender XDR alert and email notifications with tuning, suppression, and correlation; setting Microsoft Defender for Endpoint advanced features, attack surface reduction rules, custom data collection, and device groups; managing automated investigation and response, automatic attack disruption, Microsoft Sentinel automation rules, and playbooks; configuring the Microsoft Sentinel platform with roles, retention tiers, workbooks, and SOC optimization; selecting data connectors for Windows security events, Syslog, and CEF; ingesting Azure activity, threat indicators, and custom logs; building Microsoft Defender XDR custom detection rules from Advanced Hunting; and authoring Microsoft Sentinel analytics rules and anomalies mapped to the MITRE ATT&CK matrix.

   How to study it. Work in the Microsoft Sentinel and Microsoft Defender portals rather than reading. Set an attack surface reduction rule to Audit and watch the would-be blocks land in DeviceEvents. Build a scheduled analytics rule, then a near-real-time rule, and compare their latency and source limits. Save an Advanced Hunting query as a Microsoft Defender XDR custom detection and confirm it requires a Timestamp and an impacted entity column. Create an automation rule that runs a playbook on incident creation. Assign a Microsoft Sentinel Contributor role at workspace scope and trace what it can and cannot do. Configure an Azure Policy deployIfNotExists assignment to stream diagnostic logs to the workspace, and contrast it with a per-resource diagnostic setting and the Azure Activity connector.

   Easy to confuse

   • Microsoft Sentinel analytics rule versus Microsoft Defender XDR custom detection rule. A Sentinel analytics rule runs KQL against the Log Analytics workspace tables and raises Sentinel incidents; a Defender XDR custom detection runs KQL over the Advanced Hunting schema in the Defender portal and raises Defender alerts with built-in response actions on the impacted entities. If the requirement is detect over Defender endpoint or identity tables with device or user response actions, it is a custom detection.
   • Automation rule versus playbook. An automation rule is the Microsoft Sentinel trigger-and-condition layer that decides when to act on an incident or alert and can change status, assign owner, or call a playbook; a playbook is the Logic App that performs the external actions such as posting to a channel or blocking an account. If the requirement is the orchestration logic and ordering, it is an automation rule; if it is the action being run, it is a playbook.
   • Scheduled analytics rule versus near-real-time (NRT) analytics rule. A scheduled rule runs its KQL on a defined interval and look-back window and can join and aggregate broadly; an NRT rule evaluates one source nearly as events arrive for sub-minute latency but is limited to a single table and no joins. If the requirement is lowest possible detection latency on one source, it is NRT; if it needs aggregation across tables, it is scheduled.

   Worked example from the SC-200 bank

   lock_openFree sampleManage a Security Operations Environmentmedium

   Your organisation wants to enable the attack surface reduction rule that blocks executable content from email clients and webmail across all onboarded Windows devices. Security operations is concerned that a small number of line-of-business workflows might rely on this behaviour, and they must measure the real-world impact for two weeks before any block takes effect, while still generating telemetry the team can hunt over. How should the rule be configured for this initial rollout?

   • ASet the rule to Block, then add per-application exclusions for any line-of-business tool that breaks, so the rule enforces immediately while the discovered exceptions keep the workflows running during the trial.
   • BSet the rule to Warn, which prompts the user with a dismissible message each time the rule triggers, so end users decide whether to proceed while the team reviews how often the prompt is dismissed.
   • CSet the rule to Audit, which lets the offending action proceed but records a DeviceEvents entry each time the rule would have triggered, so the team can measure impact for two weeks before switching it to Block.check_circle Correct
   • DSet the rule to Not configured, then rely on Microsoft Defender for Endpoint device discovery to passively report which devices use email-borne executables, so impact is gauged without enabling the rule at all.

   Use ASR rule Audit mode to log would-be blocks to DeviceEvents and measure impact before promoting a rule to Block enforcement. An attack surface reduction rule set to Audit still evaluates the rule logic but allows the action to complete, writing an event to the DeviceEvents table each time the rule would have blocked. This produces measurable, huntable telemetry across the fleet during a pilot, so the team can size the line-of-business impact and build exclusions before switching the same rule to Block.

   Why A is wrong: Block enforces straight away, which is exactly what the requirement forbids during the measurement window, and chasing breakages with exclusions reacts after disruption has already occurred rather than measuring impact safely first.

   Why B is wrong: Warn does surface the rule and can be bypassed by the user, but it already disrupts the workflow with a prompt and is not the non-intrusive measurement mode the requirement calls for during a silent two-week impact assessment.

   Why C is correct: Audit mode evaluates the rule and logs every would-be block to DeviceEvents without stopping the action, giving the exact telemetry needed to gauge impact over the trial before promoting the rule to Block enforcement.

   Why D is wrong: Not configured leaves the rule inactive so it produces no ASR evaluation telemetry, and device discovery inventories unmanaged devices on the network rather than recording which workflows the rule would have blocked.

2. Respond to Security Incidents

   37% of exam

   What you must be able to do. Select the correct Microsoft Defender or Microsoft Sentinel investigation view, verdict, or response action that contains and remediates a stated threat across the right workload.

   In one sentenceThe response layer: cross-workload incident correlation, device timelines and live response, identity and cloud app verdicts, Purview investigation, and automatic attack disruption.

   Recall check: answer these from memory first

   • Which part of the Microsoft Defender XDR incident view shows correlated alerts, affected entities, and their relationships as one connected attack timeline?
   • Which live response command executes a pre-approved script already uploaded to the live response library on the target device?
   • In Microsoft Entra ID Protection, which action records a true-positive verdict, raises risk to high, and feeds the detection model?
   • Which Microsoft Purview capability places a legal hold and supports defensible search and export for a formal legal matter?

   What it tests. Whether you can triage and remediate real attacks across the Microsoft Defender workloads and Microsoft Sentinel: investigating and remediating threats in Microsoft Defender for Office 365, Microsoft Purview, and Microsoft Defender for Cloud; investigating identity and cloud app risk with Microsoft Defender for Cloud Apps, Microsoft Entra ID, and Microsoft Defender for Identity; managing Microsoft Sentinel incidents with agentic AI, embedded Copilot for Security, and case management; investigating multi-stage, multi-domain, and lateral-movement attacks; reading Microsoft Defender for Endpoint device timelines, evidence, and entities; performing device response actions including live response and automatic attack disruption; and investigating Microsoft 365 activity with Microsoft Purview Audit, Content Search, and Microsoft Graph activity logs.

   How to study it. Open a correlated incident in Microsoft Defender XDR and study the incident graph and attack story across email, identity, and endpoint. Drill into a device page and use the Incidents and alerts tab and the Timeline tab so you know which answers which question. In a live response session, practise the run, putfile, getfile, and library commands and learn how they differ. In Microsoft Entra ID Protection, confirm a user compromised and contrast it with dismiss, block, and reset password. In Microsoft Purview, compare eDiscovery (Premium) holds and defensible export against Content Search and Audit (Premium). Read how automatic attack disruption contains an in-progress attack without an analyst.

   Easy to confuse

   • Automatic attack disruption versus automated investigation and response (AIR) versus live response. Automatic attack disruption contains a high-confidence in-progress attack in near real time by disabling accounts or isolating devices without an analyst; AIR runs an automated playbook of investigation and remediation on alerts and may need approval; live response is a hands-on remote shell where an analyst runs commands on one device. If the requirement is autonomous containment of an active attack, it is automatic attack disruption.
   • Microsoft Purview eDiscovery (Premium) versus Content Search versus Audit (Premium). eDiscovery (Premium) opens a case, places legal holds so content cannot be altered or deleted, and supports defensible review and export; Content Search finds and exports items but cannot place a hold; Audit (Premium) records who did what with extended retention but preserves no content. If the requirement is preserve against alteration then produce for a legal matter, it is eDiscovery (Premium).
   • Device page Incidents and alerts tab versus Timeline tab. The Incidents and alerts tab is a device-scoped filter of the alerts queue showing each alert's severity, status, classification, and investigation state; the Timeline tab is the chronological stream of process, file, registry, and network events on the device. If the requirement is count active detections on one machine, it is Incidents and alerts; if it is reconstruct what happened event by event, it is Timeline.

   Worked example from the SC-200 bank

   lock_openFree sampleRespond to Security Incidentshard

   A security operations team is investigating an incident in Microsoft Defender XDR that began with a phishing email, progressed to a malicious sign-in, and then to suspicious process execution on a server. The analysts want to see how these alerts from Microsoft Defender for Office 365, Microsoft Entra ID, and Microsoft Defender for Endpoint were correlated into a single attack, including the timeline and the relationships between the involved entities. Which part of the Microsoft Defender XDR incident view should the analysts open to see this correlated end-to-end picture?

   • AThe Microsoft Defender vulnerability management dashboard, which ranks exposed devices by their weaknesses so the team can see which assets the attacker most likely targeted during the campaign.
   • BThe advanced hunting schema reference, which documents the available tables and columns so analysts can build a custom query that reconstructs the sequence of events for the incident.
   • CThe threat analytics report for the relevant campaign, which describes the actor techniques and supplies recommended mitigations the team should apply to reduce the impact of the attack.
   • DThe incident graph and attack story, which lay out the correlated alerts, affected assets, and entity relationships across the workloads as a connected timeline of how the attack unfolded.check_circle Correct

   Use the Microsoft Defender XDR incident graph and attack story to understand how cross-workload alerts correlate into a single multi-stage attack. Microsoft Defender XDR automatically correlates related alerts from across its workloads into a single incident. The incident graph and attack story render those alerts, the affected entities, and their relationships as a connected timeline, so analysts can trace how an attack moved from email to identity to endpoint without manually piecing the stages together.

   Why A is wrong: Vulnerability management surfaces device exposure and misconfigurations to drive proactive hardening, which is tempting when assessing attacker reach; it does not correlate alerts or render an incident timeline, so it cannot show how the stages connected.

   Why B is wrong: The schema reference helps an analyst write hunting queries and could be used to rebuild a sequence manually, but it is documentation rather than the built-in correlated view; the incident already provides the joined attack story without query effort.

   Why C is wrong: Threat analytics gives intelligence on actors and techniques with mitigation guidance, which feels relevant to a campaign; it is generic reporting and does not display this specific incident's correlated alerts, entities, or timeline.

   Why D is correct: The incident graph and attack story are purpose-built to visualise how alerts from different Defender workloads were stitched into one incident, showing the entity relationships and the chronological progression an analyst needs to understand a multi-stage, multi-domain attack.

3. Perform Threat Hunting

   22% of exam

   What you must be able to do. Pick the correct Advanced Hunting table, KQL operator, hunting artefact, or notebook capability that answers a proactive hunting requirement with the right telemetry and result shape.

   In one sentenceThe hunting layer: choosing the right Advanced Hunting table and KQL operator, working bookmarks into cases, data lake KQL jobs and summary rules, and Notebooks with MSTICPy and the MCP Server.

   Recall check: answer these from memory first

   • Which Advanced Hunting table records one row per process creation with both the child and the initiating-parent command lines?
   • Which KQL operator builds an evenly spaced, gap-filled time series so periodic beaconing stands out, where summarize with bin would skip empty buckets?
   • How does a threat hunter get a Microsoft Sentinel bookmark investigated in a case without authoring an analytics rule?
   • How does the Microsoft Sentinel MCP Server authenticate clients so actions inherit the signed-in user's workspace permissions?

   What it tests. Whether you can hunt proactively across Microsoft Defender XDR and Microsoft Sentinel: detecting threats by selecting the right Advanced Hunting table and writing KQL; interpreting threat analytics and analysing entity relationships with hunting graphs and Sentinel Graph; creating and managing Microsoft Sentinel hunting queries, bookmarks, KQL jobs in the data lake, and summary rule tables; and hunting with Notebooks in Microsoft Sentinel including connection to the Microsoft Sentinel MCP Server. The KQL focus is real: you must know which table carries which telemetry, and which operator produces the shape of result the hunt needs.

   How to study it. Write KQL against the real Advanced Hunting schema. Learn that DeviceProcessEvents carries both child and initiating-parent command lines while DeviceEvents is the general endpoint table, and that DeviceNetworkEvents holds outbound connections. Build a make-series query to spot beaconing and prove that summarize with bin drops empty intervals. Capture a hunting bookmark in Microsoft Sentinel, annotate it with MITRE ATT&CK tactics, and add it to an incident without authoring an analytics rule. Stand up a Jupyter Notebook with MSTICPy for multi-provider enrichment and an interactive map. Read how the Microsoft Sentinel MCP Server authenticates each user through Microsoft Entra ID so actions inherit that user's workspace permissions.

   Easy to confuse

   • DeviceProcessEvents versus DeviceEvents. DeviceProcessEvents is the dedicated process-creation table pairing the spawned process FileName and ProcessCommandLine with the InitiatingProcess parent fields, so it carries full lineage from one table; DeviceEvents is the general catch-all endpoint table for assorted actions such as ASR triggers and is not the right source for parent and child command lines. If the requirement is reconstruct a process chain, it is DeviceProcessEvents.
   • make-series versus summarize with bin. make-series aggregates a metric over a fixed step across an explicit from-to range and fills empty intervals with a default, producing a continuous series; summarize with bin groups counts per interval but omits any bucket with no events, so gaps disappear and a periodic pattern is hard to see. If the requirement is an even, gap-filled timeline for beaconing, it is make-series.
   • Hunting bookmark added to an incident versus converting a hunting query to an analytics rule. Adding a bookmark to a new or existing incident links the captured evidence into a case for the SOC to investigate without creating any detection; converting the query to a scheduled analytics rule makes it generate its own incidents on each run. If the requirement is investigate this one finding in a case and explicitly not author a rule, it is add the bookmark to an incident.

   Worked example from the SC-200 bank

   lock_openFree samplePerform Threat Huntinghard

   During an Advanced Hunting investigation in Microsoft Defender XDR, you must reconstruct a suspected malware execution chain on a single workstation by listing every process that was launched, together with its full command line and its initiating parent process, so that you can trace the lineage from the original loader. Which table should the Kusto Query Language (KQL) query target to obtain the parent and child process command lines directly?

   // Goal: child process, its command line, and its parent process command line
   <Table>
   | where DeviceName == "FIN-WKS-014"
   | project Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

   • ADeviceProcessEvents, because it records one row per process creation with the child FileName and ProcessCommandLine alongside the InitiatingProcess fields for the parent, giving the full lineage on the device.check_circle Correct
   • BDeviceEvents, because it is the general endpoint event table and therefore records every action a device takes, including each process that is created along with its parent and child command lines.
   • CDeviceImageLoadEvents, because the loader and every subsequently launched binary must be mapped into memory, so the image load records reveal the parent and child process command lines for the chain.
   • DDeviceFileEvents, because the loader writes the child executables to disk before running them, so the file create and modify records carry the process command lines for each stage of the chain.

   Use DeviceProcessEvents in Advanced Hunting for process creation telemetry, as it carries both the child and initiating-parent command lines. DeviceProcessEvents is the schema table dedicated to process creation in Microsoft Defender for Endpoint telemetry. Each row pairs the spawned process FileName and ProcessCommandLine with the InitiatingProcessFileName and InitiatingProcessCommandLine of its parent, which lets an analyst pivot up and down the chain from a single table rather than joining across general event tables.

   Why A is correct: DeviceProcessEvents is purpose-built for process creation telemetry, exposing the spawned process command line and the InitiatingProcess parent fields in the same row, which is exactly what is needed to walk a malware execution chain on one host.

   Why B is wrong: DeviceEvents is a catch-all table for miscellaneous security and audit events such as protection toggles and ASR triggers; it does not provide a dedicated row per process creation with both the child and initiating-parent command lines, so the lineage reconstruction would be incomplete.

   Why C is wrong: DeviceImageLoadEvents tracks DLL and module loads into a process, not process creation, so it lacks a per-spawn child command line and is the wrong surface for reconstructing parent-to-child execution lineage.

   Why D is wrong: DeviceFileEvents captures file create, modify, rename, and delete activity, which is useful for tracking dropped payloads, but it does not record process command lines or parent-child execution, so it cannot reconstruct the run chain on its own.

A study plan that works

1. Read the refreshed blueprint and book a date

   Day 1

   Read the three domains from the 16 April 2026 refresh and note that Manage a Security Operations Environment is the largest, Respond to Security Incidents is close behind, and Perform Threat Hunting is the smallest. Book a provisional date now to turn open-ended study into a plan, and make sure you have a Microsoft Sentinel workspace and a Microsoft Defender XDR tenant you can configure, because this exam rewards hands-on practice over reading.

2. Build the detection and automation backbone

   Week 1

   In the Microsoft Sentinel and Microsoft Defender portals, set an attack surface reduction rule to Audit and watch DeviceEvents, build a scheduled analytics rule and a near-real-time rule side by side, and save an Advanced Hunting query as a Microsoft Defender XDR custom detection. Wire an automation rule to call a playbook on incident creation, assign a Microsoft Sentinel Contributor role at workspace scope, and configure an Azure Policy deployIfNotExists assignment for diagnostic logs.

3. Master data connectors and ingestion

   Week 1 to 2

   Configure connectors for Windows security events, Syslog, and CEF, and trace how each lands in the workspace tables. Enable the Azure Activity connector, ingest threat indicators, and add a custom log source, then contrast a per-resource diagnostic setting against the policy-driven approach so you can answer least-effort-at-scale questions. Map a handful of analytics rules to MITRE ATT&CK and read SOC optimization recommendations and retention tiers.

4. Work through cross-workload incident response

   Week 2 to 3

   Open a correlated Microsoft Defender XDR incident and study the incident graph and attack story. Drill into a device page and separate the Incidents and alerts tab from the Timeline tab. Practise live response run, putfile, getfile, and library commands. In Microsoft Entra ID Protection, confirm a user compromised; in Microsoft Purview, compare eDiscovery (Premium), Content Search, and Audit (Premium); and read how automatic attack disruption contains an active attack autonomously.

5. Drill KQL and threat hunting

   Week 3

   Write Advanced Hunting KQL daily. Learn the table map: DeviceProcessEvents for process lineage, DeviceNetworkEvents for connections, DeviceEvents as the general table. Build make-series for beaconing and prove summarize with bin drops empty buckets. Capture a hunting bookmark, tag it with ATT&CK, and add it to an incident. Run a Jupyter Notebook with MSTICPy and read how the Microsoft Sentinel MCP Server authenticates through Microsoft Entra ID.

6. Drill weak domains and space the review

   Week 4

   Use your per-domain accuracy on practice questions to attack the domains dragging you down rather than re-reading what you already know. Revisit each domain's recall prompts after a few days and again a week later, because spacing roughly doubles what sticks compared with cramming. Pay extra attention to the management domain, since it is the heaviest weighted.

7. Sit a timed mock and calibrate

   Week 4 to 5

   Take at least one full timed practice run to rehearse pacing and the flag-and-return habit. Treat the score as a per-domain readiness signal rather than one number, and review every missed question, naming the constraint in the stem you misread such as real-time versus scheduled or the wrong telemetry table, before you book or sit.

Know when you're ready

Exam-day tips

• Name the owning capability first. Decide whether the stem is about a Sentinel analytics rule, a Defender XDR custom detection, an automation rule, a playbook, a device response action, or a hunting artefact before you read the options, so you narrow the field before comparing details.
• Separate real-time from scheduled and automatic from manual. If the stem demands sub-minute latency on one source it is a near-real-time rule; if it demands autonomous containment of an active attack it is automatic attack disruption; if it demands recurring aggregation across tables it is a scheduled analytics rule.
• Pick the right telemetry table in KQL. Process lineage with parent and child command lines is DeviceProcessEvents, not DeviceEvents; outbound connections are DeviceNetworkEvents; reach for make-series, not summarize with bin, when you need an even gap-filled time series for beaconing.
• Choose the least-privilege, lowest-effort option. When more than one configuration would technically work, the exam wants the narrowest scope and the fewest manual steps, such as Microsoft Sentinel Contributor over a subscription role, or an Azure Policy deployIfNotExists over per-resource diagnostic settings.
• Match the verdict to the workload. In Microsoft Entra ID Protection use Confirm user compromised to record a true positive; in Microsoft Purview use eDiscovery (Premium) for holds and defensible export; on a device use the live response run command to execute a pre-approved library script.
• Use the incident graph and attack story for correlation questions. When a stem asks how cross-workload alerts connect into one multi-stage attack, the answer is the incident graph and attack story, not threat analytics, vulnerability management, or the schema reference.
• Flag and move on. With a fixed time limit, answer every clear question first and return to the few that need more thought, so a straightforward question late in the paper is never left unanswered.

Frequently asked questions

Related certifications

Other Security certifications with a study guide.

• FCP - FortiGate Administrator (FCP-FGT-AD) study guideFortinet
• Certified Information Security Manager (CISM) study guideISACA
• Certified in Risk and Information Systems Control (CRISC) study guideISACA
• CompTIA Security+ (SY0-701) study guideCompTIA
• Certified Information Systems Auditor (CISA) study guideISACA
• Certified Information Systems Security Professional (CISSP) study guide(ISC)2
• Microsoft Security, Compliance, and Identity Fundamentals (SC-900) study guideMicrosoft
• Microsoft Identity and Access Administrator (SC-300) study guideMicrosoft
• Microsoft Cybersecurity Architect (SC-100) study guideMicrosoft
• GitHub Advanced Security (GH-500) study guideGitHub