Manage a security operations environment →mediumMultiple Choice

SC-200 Manage a security operations environment Practice Question

You are configuring a Microsoft Sentinel analytics rule to detect brute-force attacks on your Azure Virtual Machines. The rule uses the 'SecurityEvent' table. You notice that the rule is not generating incidents even though you see failed logon events in the logs. What should you check?

⚠ Common exam trap

Many exam-takers assume the issue must be with data collection (agent or retention) when they see logs present, but the real problem is almost always a misconfigured or disabled analytics rule, specifically the query logic or the rule's enabled state.

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 analytics rule is enabled and the query is correctly filtering for event ID 4625.

The most immediate reason a rule fails to generate incidents despite seeing failed logon events is that the rule itself is either disabled or its query does not correctly filter for event ID 4625, which is the specific Windows security event ID for failed logon attempts. Even if logs are present, the analytics rule must be enabled and its KQL query must accurately target the right event ID to trigger an incident. Without this, the rule will not process the events into alerts.

Answer analysis

Option-by-option breakdown

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

✗
An automation rule is suppressing incidents with the same name.
Why it's wrong here
An automation rule that suppresses incidents with the same name acts only after the analytics rule has already detected the activity and generated an incident. Suppression may hide or close incidents, but it does not stop the analytics rule from running its query or from creating an incident in the first place, so it cannot explain a total absence of incident records.
✗
The workspace retention period is set to less than 90 days.
Why it's wrong here
Workspace retention period controls how long raw log data is stored in Log Analytics, but it has no effect on the creation of incidents by an analytics rule. Even if retention is set to less than 90 days, the rule will still evaluate newly ingested data and generate incidents as long as the query finds matches, because incident generation is independent of retention settings.
✗
The Log Analytics agent is not installed on the VMs.
Why it's wrong here
If the Log Analytics agent were not installed on the VMs, there would be no SecurityEvent data collected from those machines, and any rule querying that table would return zero results — but the question states the table already has data, which proves the agent is operating correctly. The issue is therefore not a missing agent, but rather a failure somewhere in the rule or its configuration that prevents matched events from being turned into incidents.
✓
The analytics rule is enabled and the query is correctly filtering for event ID 4625.
Why this is correct
For an analytics rule to generate incidents, it must be enabled and its query must be properly constructed to return the relevant records — in this case, failed Windows logon attempts with event ID 4625 in the SecurityEvent table. If the rule is disabled, the query uses the wrong event ID, references the wrong table, or includes an overly restrictive filter (such as an incorrect time range or a nonexistent field), no matching events are detected and no incidents are created, making this the correct root cause to suspect.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question