Pass the SC-200. Start from nothing.

What is the SC-200?

SC-200 is a Microsoft certification exam called Microsoft Security Operations Analyst. Pass it and you earn the certification Microsoft Certified: Security Operations Analyst Associate.

A security operations analyst is the person who watches over a company's computers, accounts, and cloud services, spots attacks, and stops them. The exam tests whether you can do that job using Microsoft's tools, mainly Microsoft Defender XDR and Microsoft Sentinel, plus a query language called KQL.

The exam at a glance

What the exam covers

The exam has three sections, called domains. Each has a weight, the share of questions it gets:

Modules 1 and 2 aren't exam domains. They're the foundations (security concepts and KQL) you need before the domain material makes any sense. Module 7 covers the AI features (Security Copilot, agents) that now appear throughout all three domains.

How to use this course

• Read in order. Every module builds on the previous one. Module 1 gives you the vocabulary; skipping it makes everything else harder.
• Get free hands-on practice. Reading alone won't stick. Microsoft offers free trials of Microsoft 365 E5 and free Azure credits (both explained in Module 1). Use them to click through the Defender portal and Sentinel while you study. Module 8 lists everything.
• Use the self-checks. Each module ends with questions. Answer out loud before revealing the answer. That's how you find out what you actually know.
• Tick modules off. Each module has a "mark as done" checkbox. Your progress is saved in your browser.

Before touching any Microsoft product, you need about a dozen core ideas. Every screen, alert, and exam question sits on top of these.

What is a SOC?

A SOC (Security Operations Center, said "sock") is the team responsible for detecting and responding to cyber attacks. In larger companies the work splits into tiers:

• Tier 1: Triage. Watches incoming alerts, sorts real problems from noise, handles simple cases.
• Tier 2: Investigation. Digs into confirmed incidents: what happened, how far did it spread, how do we stop it?
• Tier 3: Hunting. Doesn't wait for alerts. Actively searches the data for attacks that slipped past detection.

The SC-200 tests all three levels of that work. The daily rhythm of an analyst is a loop: detect → triage → investigate → contain → remediate → learn. "Contain" means stopping the attack from spreading (for example, disconnecting an infected laptop); "remediate" means cleaning up (removing malware, resetting passwords).

Alerts, incidents, and entities

These three words appear on nearly every screen in Microsoft's tools, and they mean different things:

• An alert is a single detection. "This laptop ran a suspicious PowerShell command" is one alert.
• An incident is a group of related alerts stitched together into one story. If the same attacker phished a user, stole a password, and then ran malware on a laptop, those three alerts become one incident.
• An entity is a thing involved in the story: a user account, a device, an IP address, a file, a mailbox. Entities are how the tools connect alerts together.

When you close an incident you classify it: a true positive (a real attack), a false positive (the alarm was wrong, nothing bad happened), or an informational / benign true positive (the detection was technically correct, but the activity was legitimate, for example a security team's own penetration test). Classifying correctly matters because Microsoft's tools learn from it.

SIEM, XDR, and SOAR: the three-letter soup

These acronyms describe categories of security tools. The exam expects you to know which Microsoft product plays which role.

• A SIEM (Security Information and Event Management) collects logs from everywhere (Microsoft products, firewalls, Linux servers, other clouds) into one place, then runs detection rules over them. Microsoft's SIEM is Microsoft Sentinel.
• XDR (Extended Detection and Response) is a set of products that deeply protect specific things (laptops, email, identities, cloud apps) and automatically correlate their alerts. Microsoft's XDR is Microsoft Defender XDR.
• SOAR (Security Orchestration, Automation, and Response) means automating responses: "when this kind of alert fires, do these steps automatically." In Microsoft's world, that's Sentinel's automation rules and playbooks, plus Defender XDR's automated investigation.

Some Microsoft geography: clouds, tenants, and on-premises

Five words appear constantly in Microsoft-land, and you need them before the product map makes sense:

• Microsoft 365 is Microsoft's office cloud: Outlook email, Teams, SharePoint, OneDrive, Windows management. Sold in license tiers; E5 is the top tier, and it's the one that includes the security tools in this course. When Module 8 says "get a Microsoft 365 E5 trial," this is what it means.
• Azure is Microsoft's infrastructure cloud: rented servers, storage, databases, and services you build things on. Microsoft Sentinel is an Azure service. An Azure subscription is simply the billing container your Azure resources live in.
• Tenant: your organization's own private instance of Microsoft's cloud. When your company signs up, it gets a tenant: its own users, mailboxes, settings, and security data, walled off from every other company's. "Related incidents in your tenant" just means "in your organization."
• On-premises (or "on-prem") is the opposite of cloud: servers physically owned and run by the company, in its own building or datacenter. Most real companies are hybrid, some on-premises, some cloud.
• Active Directory (AD) is the traditional on-premises system that stores company user accounts and passwords and decides who can log into what. It runs on special servers called domain controllers, the crown jewels of a company network, because whoever controls them controls every account. Its cloud successor is Microsoft Entra ID. Most companies run both, synced together: AD on-premises, Entra ID in the cloud.

The Microsoft security product map

Microsoft has renamed almost everything at least once, and the old names still appear all over the internet. Here's the current map. Memorize it:

MITRE ATT&CK: the attacker playbook

MITRE ATT&CK (said "attack") is a free, public catalog of how real attackers operate. It organizes attacker behavior into:

• Tactics are the attacker's goals, in rough order: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact.
• Techniques are the specific methods used to achieve each goal (e.g., "Phishing" is a technique under Initial Access).

Microsoft tags nearly every alert and detection rule with its ATT&CK tactic and technique. Sentinel even shows you a coverage view of the ATT&CK matrix so you can spot gaps (for instance, "we have no detections for Lateral Movement") and fix them. The exam loves this: expect questions that name a tactic and ask what it means, or ask how to check detection coverage.

The attacks you're defending against

You'll understand the tools much better if you know the attacks they were built to catch:

• Phishing: fake emails that trick users into clicking a link or entering a password.
• Business Email Compromise (BEC): an attacker takes over or impersonates a real mailbox to redirect payments or steal data.
• Adversary-in-the-Middle (AiTM): a fake sign-in page sits between the user and the real site, stealing the password and the session token. A session token is the digital "hand stamp" your browser holds after a successful sign-in so you don't have to log in again on every click. Steal the stamp and you're in, which is how AiTM bypasses multi-factor authentication.
• Credential theft: stealing passwords or password hashes from a machine's memory.
• Pass-the-hash / pass-the-ticket: using a stolen password hash or Kerberos ticket to log in as someone without ever knowing their password. Classic on-premises Active Directory attacks (Defender for Identity's specialty).
• Lateral movement: hopping from the first compromised machine to others, hunting for more valuable targets.
• Ransomware: encrypting a company's files and demanding payment. Usually the end of a chain that started with phishing or a stolen password days earlier.
• OAuth consent abuse: tricking a user into granting a malicious app permission to read their mailbox or files. No password stolen, but the attacker gets access anyway (Defender for Cloud Apps' specialty).

Zero Trust in one paragraph

Zero Trust is Microsoft's security philosophy: never trust, always verify. Assume attackers are already inside. Verify every sign-in explicitly, give every account the least privilege it needs, and design so that one compromised laptop or account can't take down everything. You won't get deep Zero Trust theory questions on SC-200, but the mindset explains why the tools behave the way they do.

KQL (Kusto Query Language) is how you ask questions of your security data in both Defender XDR and Sentinel. It is the single most important skill on the SC-200. Expect to read and complete KQL queries on the exam. The good news: it's much friendlier than it sounds.

The mental model: tables and pipes

All your security data lives in tables, like spreadsheets. Sign-ins are rows in one table, process launches are rows in another, emails in another. A KQL query starts with a table name, then pushes the data through a series of steps separated by the pipe character |. Each step transforms what came out of the previous one.

// "From the sign-in logs, keep only failures from the last day,
// then count them per user, highest first."
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != 0
| summarize FailedCount = count() by UserPrincipalName
| sort by FailedCount desc

(One convention to know: in the SigninLogs table, ResultType 0 means success, so ResultType != 0 means "failed sign-ins.")

The operators you must know

Time: ago() and bin()

Security questions are almost always time questions. Two functions do the heavy lifting:

• ago(1h), ago(1d), ago(30d): "this long before now." where TimeGenerated > ago(24h) means "the last 24 hours."
• bin(TimeGenerated, 1h): rounds timestamps into buckets, so you can count events per hour or per day.

// Failed sign-ins per hour over the last day, as a chart
SigninLogs
| where TimeGenerated > ago(1d) and ResultType != 0
| summarize Failures = count() by bin(TimeGenerated, 1h)
| render timechart

Strings: the three matchers (and the case trap)

• ==: exact match. Case-sensitive. =~ is the case-insensitive version.
• contains: the value appears anywhere inside the string. Case-insensitive, but slow on big data.
• has: the value appears as a whole word. Case-insensitive and much faster than contains. Prefer it when you're searching for whole terms.
• startswith / endswith: what they sound like.

summarize: the workhorse

summarize groups rows by one or more columns and computes aggregates. The ones to know:

• count(): how many rows in each group.
• dcount(Column): how many distinct values. "How many different IPs did each user sign in from?"
• min() / max() / avg(): smallest, largest, average.
• arg_max(TimeGenerated, *): for each group, return the whole row with the latest timestamp. This is the idiom for "show me each device's most recent event" and appears constantly in real queries and exam answers.
• make_set(Column): collect the distinct values into a list.

// Each user's most recent successful sign-in
SigninLogs
| where ResultType == 0
| summarize arg_max(TimeGenerated, *) by UserPrincipalName

join: combining tables

A join matches rows from two tables using a shared column. The kind decides what you keep:

• kind=inner: keep only rows that match on both sides.
• kind=leftouter: keep everything from the left table, add matches from the right where they exist.
• kind=leftanti: keep rows from the left that have no match on the right. Perfect for "devices that did X but never did Y."

// Devices that downloaded a file and then made a network connection
DeviceFileEvents
| where FileName endswith ".exe"
| join kind=inner (
    DeviceNetworkEvents
    | where RemotePort == 443
) on DeviceId

Where to practice for free

• The "Must Learn KQL" series (free online book by Rod Trent), the classic beginner path.
• KC7 (kc7cyber.com), a free game that teaches KQL through detective scenarios. Genuinely fun.
• The Defender portal's Advanced Hunting page has sample queries, and Microsoft Learn's KQL modules include a free practice environment.

Aim to be comfortable reading any query built from the operators above, and writing simple filter-summarize queries yourself. The exam mostly asks you to complete or interpret queries, not to write long ones from scratch.

Exam domain 1, "Manage a security operations environment," is the biggest slice of the exam at 40-45%. It's about configuring the tools so they detect the right things, alert the right people, and respond automatically. This module covers the Defender XDR side; Module 4 covers Sentinel.

The Defender portal

Everything happens at security.microsoft.com, one portal that hosts Defender XDR, all the individual Defender products, and (once connected) Microsoft Sentinel. As an analyst this is your home screen: incidents, alerts, hunting, threat intelligence, and settings all live here.

Notifications: making sure humans find out

Detection is useless if nobody notices. In Defender XDR settings you configure email notifications of three kinds:

• Incident notifications: email the SOC when new incidents are created (filterable by severity, service source, device group).
• Action notifications: email when a response action needs approval or completes.
• Threat analytics notifications: email when Microsoft publishes new threat intelligence reports relevant to you.

Alert tuning: cutting the noise

A busy SOC drowns in alerts, so the exam cares a lot about reducing noise correctly:

• Alert tuning rules (formerly "alert suppression"): tell Defender XDR "when an alert matches these exact conditions (this process, this device, this command line), don't show it / auto-resolve it." Use for known-safe activity like an approved admin tool that keeps triggering alerts.
• Alert correlation: Defender XDR automatically groups related alerts into incidents when they share entities (same user, device, file) or fit the same attack pattern. In settings you can influence this behavior. For example, tuning rules can change what gets correlated, and incidents can be manually merged or split when the automatic grouping gets it wrong.

Defender for Endpoint: the settings that matter

Defender for Endpoint (MDE) is the product that lives on laptops and servers. In its settings you'll find advanced features, a page of toggles the exam expects you to recognize:

• EDR in block mode: even if another antivirus is the main one, Defender's detection engine can still block what it sees.
• Live response: allows analysts to open a remote command shell on a device during investigations (there's a separate toggle to allow it on servers, and one for running unsigned scripts).
• Tamper protection: stops attackers (and users) from turning off Defender's protections.
• Automatically resolve alerts, web content filtering, custom network indicators, and integrations with the other Defender products.

Under rules settings you manage indicators (lists of file hashes, IPs, URLs, and certificates you explicitly allow or block across the fleet), plus alert tuning and web filtering policies. MDE also supports custom data collection, letting you gather extra telemetry (the stream of activity data such as processes, connections, and file changes that devices report back) beyond the default: for example, collecting additional Windows event logs or registry locations from devices so they show up in Advanced Hunting. You configure what extra data to gather in the Defender portal's endpoint settings, and it flows into the same tables you hunt in.

Beyond ASR, MDE also manages broader security policies for devices: antivirus settings (scans, cloud protection, exclusions), firewall rules, and disk encryption. These can be deployed directly from the Defender portal's endpoint security policies or through Microsoft Intune (Microsoft's device-management service). For the exam, know that these policies exist, that they're assigned to device groups, and that ASR rules are one category of them.

Attack surface reduction (ASR) rules

ASR rules are built-in guardrails that block the behaviors malware loves. For example: "block Office apps from creating child processes," "block credential stealing from the Windows security subsystem (LSASS)," "block executable content from email." Each rule can run in:

• Audit mode: don't block, just log what would have been blocked. Always start here to check for business breakage.
• Block mode: enforce.
• Warn mode: block, but let the user override.

You can add exclusions for specific files/folders that a rule keeps hitting legitimately. Exam pattern: "an ASR rule is breaking a line-of-business app (a company's own internal business application), what do you do?" Answer: audit mode first, then a targeted exclusion, never "turn the rule off everywhere."

Device groups, permissions, and automation levels

In MDE you organize machines into device groups (by name, domain, tag, OS). Device groups control two big things:

• Permissions (RBAC): which analyst teams can see and act on which machines.
• Automation level: how much MDE's robot investigator may do on its own (next section). Critical servers often get a more cautious level than ordinary laptops.

Automated investigation and response (AIR)

When an alert fires, Defender can launch an automated investigation: a bot examines the device, hunts for related malware and persistence, and produces a list of remediation actions (quarantine this file, kill this process). What happens next depends on the automation level:

• Full automation: remediation actions run automatically. Microsoft's recommended default.
• Semi-automation: actions wait in the Action center for a human to approve (variants exist: require approval for all folders, or only for core/temp folders).
• No automated response: investigations don't run.

The Action center is where you review pending and completed actions, and where you can undo a remediation if it hit something legitimate.

Automatic attack disruption

This is Defender XDR's emergency brake, and a modern exam favorite. When Defender detects a high-confidence, fast-moving attack in progress (ransomware spreading, business email compromise, adversary-in-the-middle), it can act machine-speed without waiting for a human:

• Contain device: cut a compromised machine off from the network (even one not enrolled in MDE).
• Disable user: suspend a compromised account in the middle of the attack.
• Contain user: block a compromised identity's connections to other devices.

Disrupted incidents get a special tag in the portal. Your job afterward: review what was contained, finish the cleanup, and re-enable users/devices once they're safe. Attack disruption is different from AIR: AIR is a methodical investigation robot; attack disruption is an instant circuit breaker for confirmed, spreading attacks.

Custom detection rules

When the built-in detections don't cover something you care about, you write your own: build a KQL query in Advanced Hunting, then save it as a custom detection rule. You choose:

• Frequency: how often it runs (every hour, every 3/12/24 hours, or "continuous/near real-time" for supported queries).
• Impacted entities: which column identifies the device/user/mailbox the alert should attach to.
• Actions: what happens automatically on a hit: isolate the device, quarantine a file, mark a user as compromised, and so on.

The saved rule creates real alerts that flow into incidents like any built-in detection. Managing them afterward is its own exam skill: the rules live under Hunting → Custom detection rules in the Defender portal, where you can open each rule to edit the query or actions, turn it on or off, run it on demand, or delete it. Just as important, check its last run status to spot rules that are erroring or skipping runs. Creating and managing custom detections requires the "manage security settings" permission in Defender XDR.

Sentinel is the SIEM: it collects logs from anywhere, stores them, runs detection rules over them, and automates responses. This module walks the full pipeline: getting data in → storing it → detecting threats in it → responding automatically.

The workspace and Sentinel roles

Sentinel's data lives in a Log Analytics workspace. Think of it as the database that holds all your tables. Access is controlled with Sentinel-specific roles, and the exam likes "which role is enough?" questions. Least privilege wins:

Data retention: three tiers

Storing logs costs money, and Sentinel now has a tiered system. This is new, heavily emphasized material:

• Analytics tier: hot, fully indexed, fast to query, powers analytics rules. Most expensive. Default retention with generous interactive periods.
• Data lake tier: cheap, long-term storage (up to years). You can't run real-time analytics rules on it, but you can query it with KQL jobs and summarize it (Module 6). Ideal for compliance logs and rarely-needed history.
• XDR default tier: Defender XDR keeps its own raw data (like Advanced Hunting tables) for a short window, about 30 days, at no extra cost. Sending it to Sentinel extends retention but starts costing.

Per-table, you choose the tier and the retention length. Exam pattern: "we must keep firewall logs 2 years for compliance, cheaply, rarely queried" → data lake tier.

Workbooks and SOC optimization

• Workbooks are interactive dashboards built on KQL queries: charts of sign-in failures, ingestion volume, incident trends. Sentinel ships ready-made templates (many arrive with data connectors); you can save a template as your own copy and edit it, or build one from scratch by adding query, chart, and text blocks. Viewing needs only the workspace Reader role; creating and editing needs Contributor.
• SOC optimization is Sentinel's built-in advisor. It looks at what you ingest and what you detect and recommends fixes: "you pay to ingest this table but no rule uses it" (cost optimization) or "you have coverage gaps against this attack type, add these rules" (coverage optimization). Know that it exists, what it recommends, and that you can act on recommendations directly.

Getting data in: connectors

Data enters Sentinel through data connectors. The skill the exam tests: given a data source, pick the right connector and collection method.

Two terms to internalize: the Azure Monitor Agent (AMA) is the collector software installed on machines (it fully replaced the old Log Analytics/MMA agent), and a Data Collection Rule (DCR) is the instruction sheet that tells AMA which events to collect and where to send them. DCRs can filter (e.g., "only these event IDs"), which controls both noise and cost.

Automation: rules and playbooks

Sentinel's SOAR layer has two building blocks that work together:

• Automation rules: lightweight if-this-then-that logic that runs when an incident is created or updated: change severity, assign an owner, add tags, suppress noise, close known false positives, or trigger a playbook. They run in a defined order and can expire.
• Playbooks are full workflows built on Azure Logic Apps: multi-step procedures like "post to Teams, open a ServiceNow ticket, block the IP on the firewall, disable the user." Playbooks are triggered by automation rules, or run manually by an analyst on an incident, alert, or entity.

Playbook plumbing the exam checks: a playbook needs permissions to act (usually via a managed identity, an Azure identity for the playbook itself), and Sentinel needs permission to run the playbook (that's the Automation Contributor role above). Triggers come in incident, alert, and entity flavors.

Detections: analytics rules

Analytics rules are Sentinel's detection engine. They watch incoming data and create alerts/incidents. Know the types cold:

Scheduled rules carry the detail settings: query scheduling and lookback period, entity mapping (telling Sentinel which query columns are the user/IP/host, which is what makes incidents investigable), alert grouping (bundle related alerts into one incident), and event grouping (one alert for all results vs. one per result).

Finally, the MITRE ATT&CK page in Sentinel shows which tactics and techniques your active rules cover, so you can find and fill detection gaps, tying Module 1's theory to daily practice.

Three more Sentinel features worth knowing

• Watchlists: small reference lists you upload (VIP users, terminated employees, known-safe IPs) that your KQL queries and analytics rules can look up against. Example: alert only when a watchlisted VIP has a risky sign-in.
• UEBA (User and Entity Behavior Analytics): Sentinel builds a behavioral baseline per user and device, then scores how unusual any activity is. It powers the insights you see on entity pages ("first time this user accessed this resource").
• Content hub is Sentinel's app store: packaged solutions per product (e.g., "the Palo Alto solution") that install the connector, analytics rules, workbooks, and hunting queries together, instead of you building each piece by hand.

Domain 2 (35-40% of the exam) is where you play detective. An incident appears in the queue. Now what? The general workflow is always the same, then each Defender product adds its own moves.

The universal incident workflow

• Triage: open the incident, read the story Defender assembled: which alerts, which entities, what severity. Assign it to yourself, set the status to Active.
• Investigate: walk the evidence of affected users, devices, emails, and files. Expand scope. Did it spread?
• Contain & remediate: isolate devices, disable accounts, delete emails, quarantine files.
• Close: classify as true positive, false positive, or informational, and leave notes for the next analyst.

For big investigations, the unified portal offers case management. A case bundles multiple related incidents, tasks, evidence, and notes, and can be assigned across a team. Think of a case as a folder for a whole campaign, where an incident is one attack story.

Multi-stage attacks: reading the whole story

Real attacks cross domains: a phishing email (Office 365) steals credentials (Entra ID), the attacker signs in and drops malware on a laptop (Endpoint), then moves laterally toward servers (Identity). Defender XDR's superpower is stitching all of that into one incident. The exam gives you scenarios like this and asks what happened, in what order, and what to do next. Your Module 1 attack literacy plus the product knowledge below is how you answer.

Product-by-product response moves

Defender for Office 365: email threats

Use Explorer (Threat Explorer) to search all delivered email: who else received this phishing message? From there, select messages and act: soft delete / hard delete, move to junk, or purge across all mailboxes. Automated investigation can propose these actions too. Attack disruption handles fast-moving BEC and AiTM campaigns automatically. ZAP (zero-hour auto purge) retroactively removes messages that turn out to be malicious after delivery.

Microsoft Entra ID: compromised identities

Entra ID Protection assigns risk to users and sign-ins: risky sign-ins (impossible travel, anonymous IP, unfamiliar location) and risky users (leaked credentials, accumulated risky sign-ins). Your response moves: confirm compromised or dismiss risk (this feedback trains the system), force a password reset, revoke active sessions (kills stolen tokens, the step that matters most after AiTM), or disable the account.

Defender for Identity: on-premises Active Directory attacks

MDI's sensors sit on the domain controllers (the servers that run Active Directory, see Module 1) and watch for the classic AD attack chain: reconnaissance, credential theft, pass-the-hash and pass-the-ticket (Module 1), plus two you should recognize by name: a golden ticket (the attacker forges the master sign-in ticket, letting them impersonate anyone, indefinitely) and DCSync (the attacker tricks a domain controller into handing over everyone's password data by pretending to be another domain controller). Alerts arrive tagged with the user and machines involved. Response usually means resetting the affected account's password, isolating machines, and hunting how far the attacker moved laterally. You sometimes reset the password twice in a row, because Kerberos (AD's ticket-based sign-in system) can keep an old password valid until both resets land.

Defender for Cloud Apps: SaaS and OAuth threats

Investigate anomalous cloud-app behavior (mass downloads, impossible travel within an app), review and revoke risky OAuth apps that users consented to, and enforce session policies. Exam scenario: "a user granted a suspicious app mailbox read permissions" → investigate and revoke the app in Defender for Cloud Apps.

Defender for Cloud: cloud workload alerts

Defender for Cloud raises alerts about infrastructure: a virtual machine running crypto-mining, a storage account accessed from a Tor exit node, a container breakout, suspicious database queries. It covers Azure, AWS, and GCP. Response: contain the resource (network isolation, disable keys), fix the misconfiguration that allowed it, and check the alert's remediation steps, which every alert ships with.

Microsoft Purview: data-side threats

When the question is "what did they do with the data?", Purview is the answer, with three tools you must know:

• Purview Audit is the unified audit log of user and admin activity across Microsoft 365: file accessed, mailbox rule created, permission changed, search performed. Your go-to for "what exactly did this account do last Tuesday?"
• eDiscovery / Content search: search the actual content of mailboxes, SharePoint, OneDrive, and Teams. Used to find every copy of a leaked document or every message containing a phishing link.
• Insider risk & DLP signals: Purview flags risky insiders and data loss prevention violations; those entities can surface in Defender incidents for you to investigate.

Microsoft Graph activity logs

Modern attackers often skip the user interface entirely and use stolen tokens against the Microsoft Graph API. Graph activity logs record every API call, letting you hunt token abuse and mass data access that ordinary sign-in logs miss. Recognize it as the data source for API-level investigation.

Deep-dive: Defender for Endpoint response actions

Domain 2 gives MDE its own sub-section, so know these hands-on tools well:

• Device timeline: a second-by-second history of everything on a machine: processes, files, registry, network connections. This is where you reconstruct what the malware actually did.
• Response actions on a device: isolate device (cut from network, keeps Defender connection), restrict app execution (only Microsoft-signed code runs), run antivirus scan, collect investigation package (a zip of forensic evidence such as autoruns, installed programs, network connections, and event logs, gathered for offline analysis).
• Live response: a real remote shell on the device. Browse files, pull suspicious samples, kill processes, run scripts (unsigned scripts need the advanced-features toggle from Module 3). For when clicking buttons isn't enough.
• File actions: quarantine a file across the whole fleet, add its hash as a block indicator, or submit it for deep analysis (Microsoft detonates it in a sandbox and reports what it does).
• After attack disruption auto-contains something, you review it on the device page / Action center and release the containment when remediation is done.

Investigating in Sentinel

Sentinel incidents (from analytics rules) get the same triage treatment: owner, status, severity, classification on close. Extra Sentinel tools: incident tasks (checklists attached by automation rules), the investigation graph (visual map of entities and their connections), and entity pages (a dossier per user/host/IP with timeline and insights). With Sentinel unified into the Defender portal, XDR and SIEM incidents share one queue.

Domain 3 (20-25%) reverses the direction: instead of reacting to alerts, you go looking for trouble. Hunting starts from a hypothesis ("if an attacker used technique X, it would leave trace Y in table Z") and uses KQL (Module 2) to test it.

Advanced Hunting in Defender XDR

Advanced Hunting is the KQL query surface over Defender XDR's raw data (about 30 days of it). The exam's favorite skill here is deceptively simple: pick the right table. Learn this map:

// Hypothesis: someone is using certutil.exe to download files (a
// known living-off-the-land technique)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where FileName =~ "certutil.exe"
| where ProcessCommandLine has_any ("urlcache", "downloadfile", "http")
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine

A good hunt that finds something becomes a custom detection rule (Module 3) so it fires automatically next time. That loop (hunt, find, automate) is the whole point.

Threat analytics

Threat analytics is Microsoft's threat-intelligence briefing room inside the Defender portal: reports on active threat actors, campaigns, and vulnerabilities. Each report shows your exposure: related incidents in your tenant, impacted assets, and recommended mitigations with their status. Exam angle: it's the place to answer "are we affected by this new ransomware campaign, and what should we fix?"

Hunting graphs, blast radius, and Sentinel Graph

New in the unified platform, and new on the exam: instead of reading tables, you can hunt visually. The graph tools map entities (users, devices, IPs) as connected nodes so relationships jump out:

• Hunting graphs let you expand outward from a suspicious entity. Who did this account talk to, which machines did it touch?
• Blast radius analysis answers: if this account or device is compromised, what could the attacker reach from it? It ranks the damage potential, which helps you prioritize.
• Sentinel Graph is the underlying engine that pre-computes relationships between entities across the platform's data: which accounts logged into which machines, which machines talked to each other, who has permissions where. It's what powers the hunting graph and blast-radius views: instead of you writing joins across five tables, the graph already knows the connections, and you explore them visually: click an entity, expand its relationships, follow the trail. (Don't confuse it with Sentinel's older per-incident investigation graph from Module 5, which maps only one incident's entities; Sentinel Graph spans your whole environment.)

Hunting in Sentinel

Sentinel's Hunting area gives you:

• Hunting queries: a library of prebuilt KQL hunts mapped to MITRE ATT&CK tactics, plus your own. Run them all and eyeball which return results.
• Bookmarks: save interesting query results with notes and tags; bookmarks can be promoted into incidents.
• Livestream: run a query continuously and watch new matches appear in real time.
• Hunts: group queries, bookmarks, and findings into one named investigation you can track end to end.

The data lake: KQL jobs and summary rules

Module 4 introduced the cheap data lake tier. Hunting is where you use it:

• KQL jobs: asynchronous queries against data-lake data. They aren't instant like analytics-tier queries. You submit a job, it runs, results land in a table you can analyze. Use for historical hunts ("did this IP ever touch us in the past year?").
• Summary rules: scheduled aggregations that boil huge, cheap raw data down into small summary tables stored in the analytics tier. Example: hourly totals of connections per IP from a massive stream of raw firewall logs. You get fast, cheap querying, and even analytics rules, over data you could never afford to keep hot in full.

Notebooks and the Sentinel MCP Server

Notebooks (Jupyter) are interactive documents mixing code, queries, and charts, used for advanced, repeatable hunts that go beyond what KQL alone can do (enrichment from external sources, ML, custom visualizations). The modern twist: notebooks and AI agents can connect to the Sentinel MCP Server. MCP (Model Context Protocol) is a standard that lets AI assistants query your Sentinel data directly, so an AI agent can help hunt through your data lake conversationally. For the exam, know what each piece is for; deep notebook coding isn't required.

The 2026 exam refresh added AI throughout. The audience profile now expects familiarity with "AI agents and Copilots." Here's how the pieces fit, in plain terms.

Microsoft Security Copilot

Security Copilot is an AI assistant trained for security work. It comes in two experiences:

• Embedded: built into the Defender portal, right where you work. It writes incident summaries (the attack story in plain language), suggests guided responses (recommended next steps you can trigger), generates KQL from natural language ("show me failed logons for this user last week" → a ready query), and analyzes scripts and files (paste an obfuscated PowerShell blob, get an explanation of what it does).
• Standalone: its own portal with a chat interface, promptbooks (reusable prompt sequences for repeatable investigations), and plugins across Microsoft and third-party tools.

Agentic AI

"Agentic" means the AI goes past answering questions. It carries out multi-step tasks itself: triaging a phishing report end to end, investigating an incident and drafting its findings. Microsoft ships prebuilt security agents and the exam expects you to know they can take part in investigations, with humans reviewing what they conclude.

MCP: how AI reaches your data

The Model Context Protocol (MCP) is an open standard that lets AI assistants securely connect to tools and data. The Sentinel MCP Server exposes your Sentinel data (including the data lake) so AI agents and notebooks can query it. Think of MCP as the universal adapter between AI models and your security platform.

A realistic plan

With no prior Microsoft experience, most people need roughly 6-10 weeks at about an hour a day. A shape that works:

• Weeks 1-2: Modules 1-2 here, plus hands-on KQL practice (KC7, "Must Learn KQL"). Don't rush this; it pays for itself.
• Weeks 3-4: Modules 3-4, alongside Microsoft Learn's Sentinel learning paths. Set up a free trial tenant and click through everything you read about.
• Weeks 5-6: Modules 5-7, plus the Defender learning paths.
• Final weeks: Practice assessments until you consistently score 80%+, re-reading weak areas.

The official resources (all free)

• Microsoft Learn SC-200 learning paths: the official self-paced collection (10 paths, ~90+ hours if you do everything): Defender XDR, Security Copilot, Purview, Defender for Endpoint, Defender for Cloud, KQL, and four Sentinel paths (configure, connect logs, detections & investigations, hunting). Search "SC-200 course" on learn.microsoft.com.
• The official practice assessment: on the SC-200 exam page at Microsoft Learn. Free, realistic question style, explains every answer. Your single best readiness gauge.
• Exam Readiness Zone: free official video series walking each exam domain.
• The exam sandbox (aka.ms/examdemo): practice the exam interface so nothing surprises you on the day.
• Hands-on labs: a Microsoft 365 E5 trial gives you the Defender portal; a free Azure account lets you deploy Sentinel (there's a 31-day Sentinel free trial per workspace, and its training-lab content ships sample data).

Question types you'll meet

• Multiple choice / multiple select: the bulk. Watch for "select TWO" instructions.
• Case studies: a company scenario with several pages of background, then a batch of questions. Read the questions first, then mine the scenario for answers.
• Drag-and-drop / ordering: e.g., put incident-response steps in sequence, or match connectors to data sources.
• Hot area: click the right spot or complete a KQL query from dropdowns.
• The exam may include interactive components, hands-on-style tasks in a simulated interface. Your trial-tenant clicking pays off here.

Exam-day tactics

• Manage the clock: 100 minutes for roughly 40-60 questions leaves about 1.5-2 minutes each. Flag hard ones and return; case studies deserve the most time.
• No penalty for guessing: never leave a question blank.
• Think like Microsoft: the right answer is usually the least-privilege role, the narrowest suppression, the least disruptive response action, and the built-in feature over the custom hack.
• Translate old names: if practice materials mention Azure AD, Microsoft 365 Defender, or Azure Sentinel, mentally swap in Entra ID, Defender XDR, and Microsoft Sentinel.
• Online proctoring rules. If testing from home: empty desk, no notes, no second monitor, webcam on, do the system test beforehand.

After you pass

The certification renews annually, and it's free: a short open-book online assessment on Microsoft Learn, available in the six months before expiry. Natural next steps: deeper specialization (Azure security engineer) or breadth (identity and access administrator). But first, enjoy the badge. You'll have earned it.

One quiz per module, written in the exam's style: scenario first, then the decision. Click an answer to check it instantly; every question explains itself. No scores are saved, so retake them as often as you like. If you miss more than one question in a module's quiz, re-read that module before moving on.

When you're done here, move on to the exam simulator below, which is a hundred harder questions delivered under exam conditions. After that, graduate to Microsoft's official free practice assessment, the closest thing to the real exam.

The quizzes above check that a module landed. This is a different exercise. It is a bank of 100 hard, scenario-driven questions written at the difficulty of the real SC-200, weighted roughly the way the exam is weighted, and delivered the way the exam delivers them: full screen, on a clock, one question at a time.

Pick a mode below. Nothing is fixed: every attempt reshuffles the questions, reshuffles the four or five answer options inside each one, and deals from the questions you have seen least, so two back to back fifty-question papers cover the whole bank without repeating a single item. Position tells you nothing, only the content does. You can flag anything you want to revisit, and the overview panel lets you jump around freely. Want the verdict early? Tick the reveal option before you start and every answer is graded the moment you pick it, or leave it off and hit Check this answer on individual questions when curiosity wins. Either way, checking locks that question.

When you submit you get a score scaled to 1000 with 700 as the pass mark, a breakdown by domain so you can see which area is dragging you down, and a walkthrough of every question: what you picked, what was correct, and why. The explanations for anything you missed are opened for you automatically.

Scoring here is a straight percentage scaled to 1000. Microsoft's real scaling is weighted and confidential, so treat a score in the low 700s as "borderline, keep studying" rather than a guaranteed pass. Attempts are saved in this browser only.