4.3. Hunt in the Microsoft Sentinel Platform
💡 First Principle: Some hunts need breadth: years of data, many workspaces, verbose sources too expensive to keep hot. The Sentinel platform matches each hunting need to the cheapest tool that answers it: interactive hunting queries for routine hypotheses, KQL jobs and summary rules for working with lake-scale data on a schedule, and notebooks and the MCP server for analysis that outgrows KQL.
Why care: the 2026 syllabus added most of these platform features, and older study material doesn't cover them. The exam tests whether you can match a requirement ("hunt across two years of firewall logs," "summarize 1 TB per day of DNS logs into an hourly table," "let an AI agent query the lake") to the right capability and its constraints.
Think of a research library with a reading room and archives. Hunting queries are the reference desk: fast, interactive, for questions you ask often. KQL jobs are archive requests: you submit a query, it runs against the stacks, and results are delivered to the reading room (the analytics tier). Summary rules are standing digests: every hour, a clerk condenses the day's bulky records into a short ledger you can read quickly. Notebooks are the research lab, where you bring Python and Spark to the archives for heavy analysis. The MCP server is the library's API, letting AI assistants request records in a governed way.
⚠️ Common Misconception: "Hunting queries run on a schedule and raise alerts." They run when you run them; to alert, promote a query to an analytics rule or custom detection. Two related traps: summary rules and KQL jobs are different features with different jobs, and notebooks aren't limited to the analytics tier because they read data lake tables directly.
