SC-200 · Domain 3 of 3

SC-200 Domain 3: Perform threat hunting

Threat hunting is the proactive side of the SOC role. It covers detecting threats with KQL and Advanced Hunting in Defender XDR, and with hunting queries, Data lake jobs and Notebooks in Microsoft Sentinel. KQL ties the whole exam together.

Exam weight
20–25%
Official functional groups
2
Estimated questions estimate
9–14
Suggested study time estimate
15–25 hrs

About 10 min read Reviewed October 2026

Overview

Performing threat hunting covers proactively searching for threats rather than waiting for alerts. It covers detecting threats with Defender XDR: identifying the right table for a KQL query, writing Advanced Hunting queries, interpreting threat analytics, creating hunting graphs including blast radius, and analyzing relationships between entities with Sentinel Graph. It covers detecting threats with the Microsoft Sentinel platform: creating and monitoring hunting queries, creating and managing KQL jobs in the Data lake, building Summary rule tables for querying, and hunting with Notebooks, including connecting to the Sentinel MCP Server.

Though it is the smallest group by weight, hunting depends on KQL, which also appears in detections in group 1 and investigation in group 2. The exam therefore treats KQL as a skill that spans the whole certification. This group rewards the ability to read a KQL query, choose the right table, and interpret results.

How it's tested

Expect questions that show a KQL query or a hunting need and ask what the query returns, which table to use, or which hunting feature fits. Reading KQL accurately and knowing the schema tables are the key skills. Knowing the schema tables is essential.

  • Read the KQL

    A KQL query is shown, and you must predict its output or spot what it filters or summarizes.

  • Pick the table

    A data type such as device process events or sign-ins is described, and you must choose the correct Advanced Hunting or Sentinel table.

  • Right hunting feature

    A hunting need is described, and you must choose the feature, such as a hunting query, a Data lake KQL job, a Summary rule or a Notebook.

Reasoning it through

An analyst wants to find all processes launched by a specific suspicious parent process across devices in Defender XDR. They need the table that records process creation events. The DeviceProcessEvents table holds process execution data, so the KQL query runs against it, filtered on the parent process name, rather than against a network or sign-in table.

Functional groups 2

Official functional groups from the Microsoft outline, in outline order.

3.1 Detect threats by using Microsoft Defender XDRKQL tables, Advanced Hunting queries, threat analytics, hunting graphs and Sentinel Graph.
What it means
This covers identifying the appropriate table for a KQL query, identifying threats with Kusto Query Language, creating Advanced Hunting queries over Defender XDR data, interpreting threat analytics, creating hunting graphs including blast radius, and analyzing relationships between entities using Sentinel Graph.
What to understand
Advanced Hunting queries run over Defender XDR schema tables such as DeviceProcessEvents, DeviceNetworkEvents, EmailEvents and IdentityLogonEvents, so choosing the right table is the first step. KQL operators such as where, project, summarize and join shape the results. Hunting graphs and Sentinel Graph visualize entity relationships and the blast radius of a compromise.
How it shows up
A hunting need or KQL query is shown, and you must choose the table, predict the output or interpret the result.
Common confusion
Choosing the wrong Advanced Hunting table. Process events, network events, email and sign-ins each live in distinct tables.
3.2 Detect threats by using the Microsoft Sentinel platformHunting queries, Data lake KQL jobs, Summary rule tables and Notebooks with the MCP Server.
What it means
This covers creating and monitoring hunting queries in Sentinel, creating and managing KQL jobs in the Data lake for large-scale or long-retention queries, creating and managing Summary rule tables to pre-aggregate data for faster querying, and hunting with Notebooks, including connecting to the Sentinel MCP Server for AI-assisted analysis.
What to understand
Sentinel hunting queries let analysts search proactively and bookmark findings. KQL jobs in the Data lake run queries over large or long-retention data cost-effectively. Summary rules pre-aggregate high-volume data so later queries are faster and cheaper. Notebooks support advanced, programmatic hunting, and the MCP Server connects them to AI assistance.
How it shows up
A hunting or scale requirement is described, and you must choose the Sentinel feature, such as a hunting query, a Data lake job, a Summary rule or a Notebook.
Common confusion
Confusing a Summary rule with a hunting query. Summary rules pre-aggregate data; hunting queries search it.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Kusto Query Language (KQL)

    The query language used across Defender XDR and Sentinel.

    Remember
    It underlies detections, investigation and hunting, so it spans the whole exam.
    Tested as
    Most hunting questions.
    Trap
    Underestimating KQL because hunting is the smallest group.

  • Advanced Hunting tables

    Defender XDR schema tables such as DeviceProcessEvents, DeviceNetworkEvents, EmailEvents and IdentityLogonEvents.

    Remember
    Choose the table that holds the data type you need.
    Tested as
    Table selection questions.
    Trap
    Querying the wrong table for the data.

  • Core KQL operators

    where filters, project selects columns, summarize aggregates, and join combines tables.

    Remember
    summarize with count or by groups results.
    Tested as
    Reading-KQL questions.
    Trap
    Misreading what summarize or project does.

  • Hunting graph and blast radius

    Visualizations of entity relationships and how far a compromise could spread.

    Remember
    Blast radius shows the potential impact scope.
    Tested as
    Visualization questions.
    Trap
    Treating a graph as a query result rather than a relationship view.

  • Sentinel Graph

    A capability for analyzing relationships between entities across data.

    Remember
    It is new in the 2026 objectives.
    Tested as
    Entity relationship questions.
    Trap
    Confusing it with a hunting query.

  • Sentinel hunting queries

    Proactive queries to search for threats, with bookmarks for findings.

    Remember
    They differ from analytics rules, which generate alerts automatically.
    Tested as
    Hunting feature questions.
    Trap
    Confusing hunting queries with analytics rules.

  • KQL jobs in the Data lake

    Queries run over large or long-retention data in the Sentinel Data lake.

    Remember
    Used for cost-effective queries over big or old data.
    Tested as
    Scale and retention questions.
    Trap
    Running heavy queries against the Analytics tier instead.

  • Summary rules

    Rules that pre-aggregate high-volume data into summary tables.

    Remember
    They make later queries faster and cheaper.
    Tested as
    Performance questions.
    Trap
    Confusing them with hunting queries.

  • Notebooks

    Programmatic hunting environments for advanced analysis.

    Remember
    They support complex, repeatable investigations.
    Tested as
    Advanced hunting questions.
    Trap
    Expecting them for simple queries.

  • Sentinel MCP Server

    Connects Notebooks and tools to AI-assisted analysis via the Model Context Protocol.

    Remember
    It is new in the 2026 objectives.
    Tested as
    AI-assisted hunting questions.
    Trap
    Overlooking it as a newer feature.

  • Threat analytics

    Defender XDR reports on active threats and recommended actions.

    Remember
    It guides hunting toward relevant threats.
    Tested as
    Interpretation questions.
    Trap
    Confusing it with analytics rules.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Hunting query vs. analytics rule vs. Summary rule

ConceptMeaningKey differenceCommon trap
Hunting query Proactive search over data Run manually or scheduled, does not auto-alert Confusing it with an analytics rule
Analytics rule Automated detection that creates alerts and incidents Generates alerts automatically Using a hunting query where an alert is needed
Summary rule Pre-aggregates high-volume data Speeds up later queries Confusing it with a hunting query

Analytics tier vs. Data lake KQL jobs

ConceptMeaningKey differenceCommon trap
Analytics tier Fast, interactive querying of recent data Best for current, frequent queries Running heavy historical queries here
Data lake KQL jobs Queries over large or long-retention data Cost-effective for big or old data Expecting interactive speed

Advanced Hunting tables

ConceptMeaningKey differenceCommon trap
DeviceProcessEvents Process creation on endpoints Process execution data Using it for network data
DeviceNetworkEvents Network connections from endpoints Connection data Using it for process data
EmailEvents Email flow and delivery Email metadata Using it for identity data
IdentityLogonEvents Identity sign-in activity Authentication data Using it for process data

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Wrong table

    What candidates pick
    Query DeviceNetworkEvents to find process execution.
    Why it looks right
    Both are device tables.
    Why it's wrong
    Process creation is recorded in DeviceProcessEvents; network connections are in DeviceNetworkEvents.

    Clue to watch for The data needed is process versus network activity.

  2. Hunting query auto-alerts

    What candidates pick
    Use a hunting query expecting it to generate incidents automatically.
    Why it looks right
    Both search data.
    Why it's wrong
    Hunting queries are run manually or scheduled for review; analytics rules generate alerts and incidents.

    Clue to watch for The need is automatic alerting versus proactive searching.

  3. Analytics tier for history

    What candidates pick
    Run a large query over months of old data in the Analytics tier.
    Why it looks right
    It is the familiar query surface.
    Why it's wrong
    Large or long-retention queries are better run as KQL jobs in the Data lake for cost and scale.

    Clue to watch for The query spans large or long-retention data.

  4. Summary rule hunts

    What candidates pick
    Use a Summary rule to search for a specific threat.
    Why it looks right
    Both involve data.
    Why it's wrong
    Summary rules pre-aggregate high-volume data to speed later queries; they do not hunt directly.

    Clue to watch for The goal is performance versus searching.

  5. Underrate KQL

    What candidates pick
    Skip KQL practice because hunting is only 20 to 25%.
    Why it looks right
    It is the smallest group.
    Why it's wrong
    KQL also underlies detections and investigation, so weak KQL costs points across the exam.

    Clue to watch for Not a question trap but a study-strategy warning.

  6. Graph is a query

    What candidates pick
    Treat Sentinel Graph output as a tabular query result.
    Why it looks right
    Both come from data.
    Why it's wrong
    Sentinel Graph shows relationships between entities, not a tabular result set.

    Clue to watch for The question is about entity relationships or blast radius.

Answer framework

For any Domain 3 hunting scenario, use these steps before choosing an answer.

  1. Decide whether the task is proactive hunting, automated detection or query performance optimization, since each one uses a different Sentinel or Defender feature.
  2. For KQL, identify the data type needed and choose the correct Advanced Hunting or Sentinel table before writing or reading the query.
  3. Read the query operators carefully, tracing where filters, project selections, summarize aggregations and joins to predict the output.
  4. For scale, use Data lake KQL jobs for large or long-retention data and Summary rules to pre-aggregate high-volume data.
  5. Choose the right hunting surface, using hunting queries for proactive search, Notebooks for advanced analysis, and Sentinel Graph for mapping entity relationships.

Practice question

An analyst wants to proactively search Defender XDR data for every process started by a specific suspicious executable across all managed devices. Which approach is correct?

Want more like this? The SC-200 practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Treat KQL as the skill that spans the whole exam, not just this group. Spend dedicated time writing and reading queries until you can trace where, project, summarize and join without hesitation, and until you know which schema table holds which data. This pays off in detections and investigations as well as hunting.

Next, learn the hunting surfaces and keep them distinct: hunting queries for proactive search, analytics rules for automated alerting, and Summary rules for performance. Learn when to use Data lake KQL jobs for large or long-retention data.

Then give focused attention to the newer 2026 features: Sentinel Graph, Data lake KQL jobs, Summary rules and the Sentinel MCP Server, since older study material covers them thinly. Use a Defender XDR and Sentinel trial to run real Advanced Hunting queries against sample data. This is the final group, so finish with full practice tests that mix KQL across all three groups.

FAQ

How much of SC-200 is this functional group?

Perform threat hunting is 20 to 25% of the exam, the smallest of the three groups, but KQL extends into the other two.

Why does KQL matter beyond the hunting group?

Custom detections and investigations also rely on KQL, so weak KQL costs points across the whole exam, not just in hunting.

What is the difference between a hunting query and an analytics rule?

A hunting query is a proactive search run manually or on a schedule for review. An analytics rule automatically generates alerts and incidents.

When should I use Data lake KQL jobs?

For queries over large volumes or long-retention data, which are more cost-effective in the Data lake than in the interactive Analytics tier.

What do Summary rules do?

They pre-aggregate high-volume data into summary tables so later queries run faster and more cheaply.

What is new in the 2026 hunting objectives?

Sentinel Graph, KQL jobs in the Data lake, Summary rule tables and hunting with Notebooks connected to the Sentinel MCP Server.

How does this group connect to the rest of the exam?

It hunts across the data ingested in group 1 and finds threats that become the incidents handled in group 2, with KQL linking all three.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 3 knowledge

You have covered KQL and Advanced Hunting, hunting graphs, Sentinel Graph, Data lake jobs, Summary rules and Notebooks. Test whether you can read KQL and choose the right table and feature under exam conditions.

Take the SC-200 practice test Check your SC-200 readiness

Keep going