SC-200 preparation should follow the SOC lifecycle rather than product names. Start with Sentinel and Defender XDR data/roles, then detection engineering and automation, then incident investigation across Defender products and Purview, then KQL hunting, graphs, Data lake queries, and notebooks. Keep one test incident throughout the plan so each tool adds evidence to the same investigation.
As of October 4, 2026, use the live July 28 SC-200 objectives. Microsoft has announced an English update for October 21, so candidates testing after that date should switch checklists. The current weights are 40–45% environment management, 35–40% incident response, and 20–25% threat hunting.
Phase one: understand the security-operations data plane
Review Defender XDR, Sentinel, Entra ID, Defender for Cloud, Defender for Cloud Apps, Defender for Identity, Office 365, Purview, and endpoint telemetry. Draw which product collects which kind of evidence and where incidents can aggregate it.
This prevents later study from becoming a set of disconnected portals.
Phase two: build Sentinel roles, retention, and data ingestion
Study roles, Analytics/Data lake/XDR retention tiers, workbooks, SOC optimization, Windows Security Events via AMA/DCR, WEF, Syslog/CEF via AMA, Azure diagnostics, threat indicators, and custom tables.
A Sentinel lab should prove that events land in the expected table before you write detections.
Phase three: learn Defender Endpoint policy and automation
Review advanced features, rules, custom data collection, attack-surface-reduction policy, device groups, permissions, automation levels, automated investigation/response, and automatic attack disruption.
Use a Defender for Endpoint baseline so policy, detection, and later investigation are connected.
Phase four: engineer detections
Create or study Advanced Hunting custom detections and Sentinel scheduled, NRT, threat-intelligence, ML, and anomaly detections. Map one detection to MITRE ATT&CK and document required data.
Then tune one noisy rule through suppression, correlation, or query improvement rather than simply disabling it.
Phase five: automate safe response
Use Sentinel automation rules and playbooks plus Defender automated response. For each action, define trigger, permission, evidence preserved, failure behavior, and whether human approval is required.
Automation should reduce time-to-contain without creating a second incident through excessive action.
Phase six: investigate Defender XDR incidents end to end
Practice moving across identities, endpoints, email, cloud apps, cloud workloads, and Sentinel evidence. Include a multi-stage or lateral-movement case.
A Defender for Cloud alert should be treated as one piece of the incident graph, not an isolated cloud-console task.
Phase seven: go deep on endpoint response
Use device timelines, evidence/entity investigation, live response, investigation packages, and remediation actions. Know which actions preserve investigation value and which isolate or remediate the endpoint.
Always verify impact after response so containment does not silently break a critical service.
Phase eight: add Purview and Microsoft 365 investigations
Review Purview Audit, eDiscovery Content search, Graph activity logs, compromised identities, and data-access evidence. This phase broadens incident scope beyond endpoint telemetry.
The SOC should be able to answer who accessed data, from where, through which identity, and what changed.
Phase nine: build KQL hunting fluency
Practice selecting the right table, filtering time and entities, joins, parsing, summarization, and turning a hypothesis into an Advanced Hunting or Sentinel query. Then use hunting graphs, Sentinel Graph, threat analytics, and blast-radius reasoning.
Move next into Data lake KQL jobs, Summary rule tables, and notebooks/MCP integration so the current hunting scope is covered.
Finish with closed-loop SOC scenarios
Take one attack from ingestion to detection, automated action, incident triage, endpoint/identity/cloud investigation, hunting expansion, remediation, and detection improvement. Note where AI-assisted investigation can help and where analyst validation remains necessary.
Keep one simulated organization throughout the plan. Give it Windows endpoints, Microsoft 365, Azure workloads, Entra identities, one SaaS application, and a Sentinel workspace. Reusing one tenant model makes it easier to see how the same identity appears in endpoint, email, cloud, and audit evidence.
During data-ingestion study, create a connector matrix: source, collection method, destination table, expected volume, retention need, and detection dependency. This makes the platform objective concrete and exposes when an analytics rule depends on data you have not actually collected.
During detection study, keep one hypothesis-to-rule worksheet. Write threat behavior, MITRE technique, data source, KQL or rule type, entity, severity, expected false positives, and response. Detection engineering becomes easier when each rule has a reason and an owner.
During automation study, create a playbook decision table. Low-risk enrichment can be fully automated; disruptive actions such as isolation or account changes may require stronger conditions or approval. The goal is to understand how automation levels match confidence and business impact.
During incident response, practice building a timeline across products. Start from the first identity or device event, add email/cloud/SaaS evidence, and mark lateral movement or exfiltration. A timeline helps analysts identify the sequence of attacker actions rather than reading alerts independently.
During endpoint response, distinguish collection from remediation. Investigation package and timeline evidence help reconstruct activity; live response can inspect or act; isolation or remediation changes system state. Preserve evidence before making destructive changes when the incident allows it.
During Purview study, use one user-data investigation scenario. Ask which audit or content-search evidence can show access, sharing, or modification. This keeps compliance tooling connected to security incidents rather than studied as a separate compliance certification.
During KQL study, keep the query exercises hypothesis-driven. Avoid memorizing long query strings without understanding schema. Start with table selection and a precise question, then add filters, joins, parsing, and summarization only as needed.
During advanced hunting, compare live/interactive hunting with Data lake KQL jobs and Summary rule tables. The tools serve different scale and recurrence needs. Knowing why a SOC chooses one path is more important than memorizing every syntax detail.
Before exam day, re-check the study guide date. If the English exam is still before October 21, stay on the July 28 objectives. If your booking moved to October 21 or later, update the checklist to the new version. This single step prevents studying a stale role definition.
Add one weekly connector-health review. Check whether the expected Windows, Syslog/CEF, Azure, or custom data is arriving and whether the volume is plausible. A hunting or detection exercise built on missing data teaches the wrong lesson, so data quality should be verified first.
Add one role/permission exercise in Sentinel and Defender. Use a read-only analyst, an investigator, and an automation identity conceptually or practically. This makes least privilege inside the security platform visible and helps candidates distinguish access-to-data from permission-to-remediate.
During rule engineering, practice one NRT detection and one scheduled detection for different hypotheses. Explain why each timing model fits. Then compare them with a custom Defender XDR detection so the two detection platforms remain distinct in your mental model.
During incident study, include one case that spans endpoint, identity, and cloud app evidence. Build a timeline and blast-radius graph before remediating. This reinforces the role profile’s emphasis on multi-stage and multi-domain attacks.
During automation study, deliberately create a failed playbook action in a safe lab and identify whether the cause is trigger logic, credential, permission, API, or downstream service. Successful automation needs monitoring just like any other production workflow.
During Purview study, compare audit evidence with eDiscovery content search. One helps reconstruct activity, while the other can locate content relevant to an investigation. Knowing which question each tool answers reduces confusion.
During hunting study, build one query into a detection after it proves useful. This closes the operational loop: proactive hypothesis → evidence → repeatable detection → automated or analyst response. It is one of the clearest ways to understand how hunting improves the SOC.
Add one long-horizon hunting scenario using the Data lake or summarized data concepts. Compare it with a recent incident query over interactive data. The difference helps candidates remember why Sentinel now exposes multiple storage/query tiers.
Use the last days for date-aware change review. Read the October 21 change log without replacing the live July 28 checklist prematurely. Identify which objectives change so you can pivot quickly if the booking crosses the update date.
Finish with one closed-book explanation of the role: configure the SOC environment, ingest data, build detections, automate safe response, investigate incidents across products, hunt with KQL and graphs, then improve controls from lessons learned. If that flow is natural, the products have become one security-operations practice.
Add one final permission review covering Sentinel roles, Defender device-group permissions, automation identities, and access to Purview or other investigation data. Security operations tooling itself needs least privilege; an analyst should have enough authority to investigate and respond without receiving unnecessary administrative access everywhere.
Keep a small “current-versus-upcoming” note with the October 21 change date and the few objectives that move. This prevents last-minute confusion while still letting you prepare for the live version today. Date-aware scope control is especially important for Microsoft role exams because the platform evolves quickly.
Before the exam, explain one incident to another person without opening a portal: where the data was collected, which detection fired, what automation did, which entities were involved, what KQL/hunting added, how remediation was validated, and which environment control changed afterward. That verbal walkthrough is a strong readiness test.
Keep that closed-loop explanation concise, evidence-driven, and aligned to the live July 28 objectives until the update date arrives.
Use that scope consistently.
Precisely.
Within the broader Microsoft certification path, SC-200 is a role exam. You are ready when you can reduce risk through the whole operations loop rather than only navigate individual security products.