Perform threat hunting
Sentinel Hunting, Data Lake, and Notebooks
CoreOperationalize proactive hunts, process long-retained lake data, preaggregate recurring queries, and use notebooks or MCP connections within controlled identities and scopes.
Aligned to SC-200 skills measured as of July 28, 2026; product behavior verified September 18, 2026.
Why this matters
Interactive queries are not the best tool for every volume or workflow. Reusable hunting queries support recurring analyst decisions, KQL jobs process large lake ranges asynchronously, summary rules reduce repeated aggregation cost, and notebooks support code-based enrichment.
Must Know
- Saved Sentinel hunting queries capture repeatable KQL, entity mappings, time ranges, and a hypothesis for periodic analyst review.
- KQL jobs asynchronously process Sentinel data-lake records and can persist results into a destination table.
- Summary rules periodically aggregate high-volume source data into summary tables; binning, frequency, and lookback must avoid gaps and overlap.
- Notebooks support Python, visualization, enrichment, and MSTICPy-style workflows across approved data connections.
- A Sentinel MCP Server connection should use a least-privileged identity and controlled workspace scope; natural-language output still requires source validation.
Compare and Distinguish
- A hunting query is an interactive or repeatable hypothesis; an analytics rule is a continuously evaluated detection.
- A KQL job processes data lake data asynchronously and can persist output; a summary rule periodically aggregates workspace data into a custom table.
- A notebook supports code, enrichment, visualization, and repeatable analysis; the MCP Server exposes approved Sentinel tools to compatible agents.
Scenario examples
- Scenario: A broad historical query may run for an extended period. Think: use a data lake KQL job and persist the results.
- Scenario: Dashboards repeatedly scan high-volume raw logs. Think: create a summary rule table with the required aggregation cadence.
- Scenario: Analysts need code-driven enrichment and graphing. Think: use a notebook; grant an MCP connection only the approved tools and scope.
Exam traps
- A hunting query that returns no rows after a schema migration may be broken rather than reassuring.
- A successful KQL job can write zero rows when the source time range or filter matches nothing.
- An incident automation rule does not preaggregate source events.
- Shared notebook cells must not contain reusable secrets or tenant-wide owner credentials.
Key takeaways
- Choose hunting queries for repeatable hypotheses, KQL jobs for lake-scale processing, and summary rules for recurring aggregates.
- Use notebooks when the investigation needs code, enrichment, or custom visualization.
- Keep data and tool access scoped, auditable, and evidence driven.
How it works
- Hunting queries run KQL over available Sentinel data and can map results to investigation entities.
- KQL jobs and summary rules write derived results; notebooks and MCP clients access data through their configured identities and connections.
Objects and administrative surfaces
- Microsoft Sentinel Hunting for saved queries, bookmarks, and results.
- Sentinel data lake for KQL jobs over retained data.
- Azure Monitor summary rules and custom tables; notebooks with authenticated data access.
When to use it
- Use the data lake when the hunt must scan long-retained or very large records.
- Use a notebook when Python, statistical methods, visualization, or external enrichment is central to the analysis.
Security and governance implications
- Use managed or otherwise protected credentials for notebooks, APIs, and MCP connections.
- Scope tool identities to the required workspace and keep derived tables under the same data governance controls.
Troubleshooting signals
- For empty KQL-job output, inspect source scope, run window, filters, and destination mapping.
- For summary errors, compare frequency, lookback, bin size, and prior run overlap.
More detail
- Saved Sentinel hunting queries capture repeatable KQL, entity mappings, time ranges, and a hypothesis for periodic analyst review.
- KQL jobs asynchronously process Sentinel data-lake records and can persist results into a destination table.
- Summary rules periodically aggregate high-volume source data into summary tables; binning, frequency, and lookback must avoid gaps and overlap.
- Notebooks support Python, visualization, enrichment, and MSTICPy-style workflows across approved data connections.
- A Sentinel MCP Server connection should use a least-privileged identity and controlled workspace scope; natural-language output still requires source validation.
Ready for the quiz?
- When should a KQL job replace an interactive six-month scan?
- Which time settings can cause summary-table double counting?
- What permissions should an MCP client receive for a single-workspace investigation?
Related objectives
- D3.2.S1 — Create and monitor hunting queries
- D3.2.S2 — Create and manage KQL jobs in Data lake
- D3.2.S3 — Create and manage Summary rule tables for querying
- D3.2.S4 — Hunt for threats by using Notebooks, including connection to the Sentinel MCP Server