Manage a security operations environment →mediumMultiple Choice

SC-200 Manage a security operations environment Practice Question

Your security operations team uses Microsoft Sentinel workbooks to monitor security posture. You notice that a workbook query is timing out when run against a large workspace. What is the best way to optimize the query without changing its results?

⚠ Common exam trap

Watch out — candidates often confuse query optimization with result modification, choosing to reduce the time range or remove filters, which changes the data returned, rather than using workspace scoping to limit the data source without affecting the query logic.

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

✓

Use the workspace() function to query specific workspaces only.

The `workspace()` function in KQL allows you to explicitly scope a query to specific workspaces, reducing the data scanned and improving performance. By targeting only the necessary workspaces, you avoid the overhead of querying the entire large workspace, which is the root cause of the timeout. This optimization does not alter the query logic or results, as it simply restricts the data source.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Remove some filter conditions to simplify the query.
Why it's wrong here
Removing filter conditions broadens the set of raw rows KQL must read because each predicate acts as a storage-level pruner that skips irrelevant partitions and rows. The query result would no longer represent the same security baseline, so any performance gain comes at the cost of correctness and completeness. A workbook user cannot simplify filters without changing the analytic meaning of the visualization.
✗
Add a summarize operator at the end of the query.
Why it's wrong here
A summarize operator placed after the final table scope only aggregates rows that have already been fetched and projected, so the initial data scan still touches every matching record across the time range and workspace set. Sentinel's storage engine cannot push row reduction into the scan based solely on a trailing aggregation. This approach may actually increase CPU and memory usage while leaving the underlying data access volume unchanged.
✓
Use the workspace() function to query specific workspaces only.
Why this is correct
Using the workspace() function, such as workspace('ContosoSOC'), explicitly constrains the query to named Log Analytics workspaces, which lets the execution engine skip irrelevant workspace partitions entirely. In Microsoft Sentinel workbooks, this is a standard way to avoid querying all accessible workspaces when the security data of interest is known. It reduces the data volume analyzed, improves query response time, and preserves the intended results as long as the targeted workspace holds the needed tables.
✗
Reduce the time range of the query.
Why it's wrong here
Reducing the time range changes the predicate applied to the TimeGenerated column, so events that fall outside the new window are excluded from the result set. Even if this makes the workbook query run faster because fewer data partitions are read, it invalidates the visualization or detection by removing legitimate events from the analysis. The correct optimization should keep the original temporal scope and instead reduce the data scanned by narrowing the workspace or table scope.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question