Respond to security incidents →mediumMultiple Choice

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.

```kql
// KQL query from Microsoft Sentinel
DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "ProcessCreated"
| where InitiatingProcessFileName == "powershell.exe"
| where ProcessCommandLine has "-EncodedCommand"
| project Timestamp, DeviceName, FileName, ProcessCommandLine
| take 100
```

You are investigating a potential malicious PowerShell execution in Microsoft Defender for Endpoint using this KQL query in Advanced Hunting. The query returns no results. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates may focus on column names or time ranges, overlooking the fundamental table mismatch between 'DeviceEvents' and 'DeviceProcessEvents' in Microsoft Defender for Endpoint Advanced Hunting.

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

✓

The table name should be 'DeviceProcessEvents' instead of 'DeviceEvents'.

The query uses the table 'DeviceEvents', which is incorrect for hunting process execution events. The correct table for process creation events in Microsoft Defender for Endpoint Advanced Hunting is 'DeviceProcessEvents'. 'DeviceEvents' contains other types of events (e.g., registry, file, network) but not process creation data, so the query returns no results.

Answer analysis

Option-by-option breakdown

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

✗
The column names are incorrect; 'InitiatingProcessFileName' should be 'ParentProcessFileName'.
Why it's wrong here
The column names in the query are actually correct for the DeviceProcessEvents schema. 'InitiatingProcessFileName' is the standard column name for the parent process's file name, and 'ParentProcessFileName' is not a valid column in this table. Therefore, the query failure is not due to a column naming issue; the schema aligns with Microsoft Defender for Endpoint's process events.
✓
The table name should be 'DeviceProcessEvents' instead of 'DeviceEvents'.
Why this is correct
The root cause is that the query queries the DeviceEvents table, which does not contain process creation events. Process creation events are stored in the DeviceProcessEvents table, part of the Advanced Hunting schema. Querying DeviceEvents will not return process creation data, even if the rest of the query is correct. Changing the table to DeviceProcessEvents resolves the issue.
✗
The 'take 100' operator limits results to only 100, but the query may return results if more data exists.
Why it's wrong here
The 'take 100' operator only limits the number of rows returned, not the rows scanned or the query's ability to produce results. If there are any matching events, 'take' will return up to 100 of them, not zero. Therefore, a lack of results cannot be attributed to the 'take' operator; it simply caps output for readability.
✗
The query uses 'ago(7d)' which may be too short for historical data.
Why it's wrong here
The time range of 'ago(7d)' is a common and reasonable default for many investigations, and it is not overly restrictive. If events occurred within the last 7 days, they would be included in the query. The absence of results is more likely due to the incorrect table name, not the time filter. Extending to a longer range might be worthwhile only if the incident is known to be older.

Go deeper

SC-200 Respond to security incidents Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question