ExamworthyExamworthy
Open the appStart free

SC-200 - Perform Threat Hunting - Section 3.3

Create and manage Microsoft Sentinel hunting queries, KQL jobs in the Data lake, and Summary rule tables.

Create and manage hunting queries and bookmarks in Microsoft Sentinel to track leads and share findings across the SOC team. Run KQL jobs against the Data lake tier for large-scale historical searches, and use Summary rule tables to pre-aggregate frequent query patterns for faster ongoing hunting.

hunting queries and bookmarksmonitoring hunting queriesKQL jobs in Data lakeSummary rule tables for querying

Practice question for this objective

Free samplePerform Threat Huntingmedium

Your organisation sends high-volume, low-value network logs to the Microsoft Sentinel data lake tier for cheap long-term storage instead of to the analytics tier. A hunter must now run a large, ad hoc Kusto Query Language (KQL) query across several months of records that live only in the data lake tier, as a one-off batch operation that writes its output into a new table for further analysis. Which Microsoft Sentinel data lake capability is purpose-built for that?

  • ACreate a KQL job, because a KQL job runs a KQL query as an on-demand batch operation over data lake tier data and writes its full results into a destination table for later analysis. Correct
  • BRun an interactive query in the Logs experience, because that surface runs KQL fast enough to scan months of data lake tier records directly during a single hunting session.
  • CStart a search job, because a search job runs KQL over a workspace table to retrieve matching records into a results table and therefore also covers data held in the data lake tier.
  • DConfigure a summary rule, because it runs KQL on a schedule over the verbose data lake logs and is the supported way to query large historical volumes from the lake on demand.
Use a KQL job in the Microsoft Sentinel data lake to run a batch KQL query over data lake tier data and write the results into a destination table. A KQL job in the Microsoft Sentinel data lake runs a KQL query as an on-demand or scheduled batch operation over the high-volume, low-cost data lake tier and writes its full results to a destination table. That is the intended path for a large ad hoc hunt across months of data lake records. It differs from the interactive Logs experience and search jobs, which operate on analytics-tier workspace tables, and from summary rules, which produce scheduled aggregated rollups rather than a one-off full-fidelity scan.

Why A is correct: A KQL job is the data lake feature that executes a KQL query as a batch operation across data lake tier records and persists the output to a destination table, which exactly matches the one-off, multi-month, full-fidelity analysis the hunter needs.

Why B is wrong: The interactive Logs experience is tempting because it is the default place hunters write KQL, but it queries analytics-tier tables for fast exploration rather than running a batch operation over the data lake tier, so it does not fit a months-long one-off scan.

Why C is wrong: A search job is the closest near-miss because it does run KQL as a job and writes a results table, but it targets analytics-tier workspace tables including long-term retention, not the separate data lake tier, so it is not the data lake batch-query mechanism described.

Why D is wrong: A summary rule sounds plausible because it also runs KQL against data lake data, but it produces scheduled aggregated rollups to cut cost rather than a one-off full-fidelity scan, so it cannot return the raw multi-month result set the hunt requires.

See more SC-200 practice questions, answers explained.

More in this domain

Back to all Perform Threat Hunting objectives, or the SC-200 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.