SC-200 Perform threat hunting Practice Question
While hunting in Microsoft Sentinel, you find a KQL query that uses the `evaluate` operator with `bag_unpack` to expand JSON properties. The query runs slowly and times out. What is the best practice to optimize this query?
⚠ Common exam trap
SC-200 often tests the principle of filtering before expensive operators — candidates incorrectly choose scaling or materialize instead of reducing input rows before bag_unpack.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a `where` clause to filter rows before applying `bag_unpack`.
The best practice for optimizing KQL queries that use bag_unpack is to filter rows with a where clause before applying the expansion. bag_unpack is expensive because it dynamically expands JSON properties into columns, so reducing the row set first minimizes the work. This is the correct optimization because it addresses the root cause: processing too many rows through an expensive operator.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the cluster's concurrency and nodes.
Why it's wrong here
Scaling out compute resources (adding nodes or raising concurrency) can hide symptoms of a heavy query, but it does not reduce the per-row work `bag_unpack` performs. If the query is poorly shaped, you still pay the same expansion cost on every row; the real fix is to reduce input cardinality or choose a more targeted operator, not to throw more hardware at the problem.
- ✗
Remove the `evaluate` operator and use `extend` with `parse_json`.
Why it's wrong here
Replacing `evaluate bag_unpack()` with `extend` plus `parse_json()` abandons the native operator designed for efficient JSON property expansion. `bag_unpack` handles dynamic bags in a single vectorized pass, while per-row `parse_json()` then `extend` multiplies parsing overhead and still evaluates the full dataset, so it typically degrades performance rather than improving it.
- ✓
Add a `where` clause to filter rows before applying `bag_unpack`.
Why this is correct
Placing a `where` clause before `bag_unpack` reduces the number of rows entering the expansion, which is the most direct way to cut the CPU and memory cost of unpacking. Filtering on a non-computed column (or an indexed field) lets the engine prune data early, so `bag_unpack` operates on a minimal logical set and the query's overall runtime drops substantially.
- ✗
Use the `materialize` function to cache the entire table before expansion.
Why it's wrong here
`materialize()` does create a cached copy of the table, but caching alone does not shrink the row set passed to `bag_unpack`. In fact, caching the entire table before expansion can spike cluster memory, and because the query references the cache only once, the overhead of materialization adds no optimization benefit while the expansion still processes every row.
Go deeper
Related to this question
About these practice questions
One of 1,303 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This SC-200 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-200 exam.