Perform threat hunting →hardMultiple Choice

SC-200 Perform threat hunting Practice Question

Your organization uses Microsoft Sentinel and Microsoft Defender XDR. You want to create a hunting query that finds users who have accessed a high number of distinct Azure resources within a short time frame, which may indicate credential theft. Which KQL query would be most effective?

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

✓

AzureActivity | where TimeGenerated > ago(1d) | summarize dcount(Resource) by Caller, bin(TimeGenerated, 1h) | where dcount_Resource > 20

It uses the AzureActivity table to count distinct resources per user per hour, filtering for those with more than 20 resources. Option A is wrong because it uses a 1-minute bucket, too granular for meaningful hunting. Option B is wrong because it counts operations, not distinct resources. Option C is wrong because it counts distinct operation names, not resources.

Answer analysis

Option-by-option breakdown

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

✗
AzureActivity | summarize dcount(Resource) by bin(TimeGenerated, 1m), Caller
Why it's wrong here
The 1-minute bin is too short to capture meaningful reconnaissance behavior; an attacker can legitimately touch dozens of resources in a burst of scripted activity, so a high count per minute is noisy and not a stable signal. Additionally, the query lacks a time filter (no ago()) and scans the entire AzureActivity table, making it inefficient and prone to including stale, irrelevant data. A rapid resource enumeration pattern is better detected over a one-hour window, as in the correct answer.
✗
AzureActivity | summarize count() by Caller | where count_ > 20
Why it's wrong here
This query uses count() to tally the total number of AzureActivity log entries per caller, not the number of distinct resources, so a user who repeatedly performs many operations on one resource (e.g., 50 updates to a single VM) will falsely trigger the >20 threshold. It also has no bin() for time, meaning it aggregates across the entire log history, which can mask recent spikes or create baseline-dependent thresholds. The correct detection should focus on distinct Resource values per time period, not raw event volume.
✗
AzureActivity | summarize dcount(OperationName) by Caller, bin(TimeGenerated, 1h) | where dcount_OperationName > 20
Why it's wrong here
Here dcount(OperationName) measures the variety of operation types (such as reads, writes, and deletes) rather than the scope of resources touched. An actor could invoke a handful of operation types against hundreds of resources, or dozens of operation types against one resource, so this query does not actually detect rapid resource reconnaissance. It also omits a TimeGenerated filter, so the hourly bin applies to the entire historical dataset, making any threshold meaningless for near-real-time alerts.
✓
AzureActivity | where TimeGenerated > ago(1d) | summarize dcount(Resource) by Caller, bin(TimeGenerated, 1h) | where dcount_Resource > 20
Why this is correct
This query correctly isolates the last 24 hours of activity, groups events by each caller (user or service principal) and by one-hour time bins, and then computes the distinct count of Resource values—the full Azure resource IDs—for each group. The filter dcount_Resource > 20 surfaces users that accessed an unusually high number of distinct Azure resources within a single hour, a pattern consistent with an attacker rapidly enumerating the environment to find high-value targets. This approach balances sensitivity and performance, and it directly maps to the MITRE ATT&CK technique T1087 (Account Discovery) or T1526 (Cloud Service Discovery) when run as a scheduled Sentinel analytics rule.

Go deeper

SC-200 Perform threat hunting Practice Question

Why each option matters

Option-by-option breakdown

Related to this question