Troubleshooting Analytics Rules Not Generating Incidents in Microsoft Sentinel
Exhibit
Refer to the exhibit.
```json
{
"properties": {
"displayName": "Malware detected on endpoint",
"severity": "Medium",
"queryPeriod": "PT5M",
"queryFrequency": "PT5M",
"triggerOperator": "GreaterThan",
"triggerThreshold": 0,
"query": "DeviceEvents | where ActionType == \"AntivirusDetection\" | where Timestamp > ago(5m)"
}
}
```Refer to the exhibit. You are creating a scheduled analytics rule in Microsoft Sentinel using the ARM template snippet. The rule runs every 5 minutes and queries the last 5 minutes of data. The rule is not generating alerts even though malware detections are occurring. What is the most likely issue?
⚠ Common exam trap
Candidates may assume that any table referenced in a query is automatically available in the Log Analytics workspace, but custom or advanced hunting tables from Microsoft Defender require explicit data connectors to be enabled.
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 DeviceEvents is not ingested into the Log Analytics workspace.
DeviceEvents is a table from Microsoft Defender for Endpoint, but it is not automatically available in Microsoft Sentinel's Log Analytics workspace. The data connector for Microsoft Defender for Endpoint must be configured and the table must be mapped to Sentinel's workspace. Without this, the query runs against an empty table, returning no results, so the rule never triggers (even with triggerThreshold of 0). Option A is incorrect: having queryPeriod and queryFrequency both set to 5 minutes is standard for a rule that runs every 5 minutes looking at the last 5 minutes; it does not cause overlapping windows. Option B is incorrect: triggerThreshold of 0 means any result should trigger an alert, but if there are no results due to missing data, the rule won't fire. Option C is incorrect: the ARM template snippet would include the required 'kind' property for a scheduled rule; its absence is not the issue here.
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 queryPeriod and queryFrequency are the same, causing overlapping windows.
Why it's wrong here
Identical queryPeriod and queryFrequency are valid and common, producing back-to-back non-overlapping windows; they do not suppress alerts. It is tempting because overlapping or gapped lookback windows genuinely cause missed or duplicated detections, so tuning queryPeriod relative to queryFrequency is the right fix when events straddle window boundaries.
- ✗
The triggerThreshold is set to 0, which should always trigger.
Why it's wrong here
A triggerThreshold of 0 means the rule fires only when the query returns zero results, so real malware detections never alert. It is tempting because the value looks like a disabled or permissive setting, and setting triggerThreshold to 0 is the correct configuration for rules designed to alert on the absence of expected events.
- ✗
The ARM template is missing the required 'kind' property.
Why it's wrong here
A missing 'kind' property causes ARM template deployment validation to fail, so the rule never exists in Microsoft Sentinel and no alerts can be produced. It is tempting because Scheduled and NRT rules do require the correct kind value, and supplying it is the right fix when a template deploys without error but the rule behaves as the wrong type.
- ✓
The table DeviceEvents is not ingested into the Log Analytics workspace.
Why this is correct
The rule queries DeviceEvents, so if that table is never ingested into the Log Analytics workspace, the query returns no rows and no alerts fire despite real malware activity. Missing ingestion is the constraint that silently breaks detection.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-200 question from scratch — 1,303 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on SC-200
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are reviewing a Microsoft Sentinel analytics rule configuration. The rule is not generating incidents as expected. What is the most likely cause?
hard- A.The queryFrequency and queryPeriod are mismatched.
- B.The suppressionDuration is set to 5 hours, suppressing alerts.
- C.The action type 'MFA disabled' is not supported in IdentityLogonEvents.
- ✓ D.The query references a table that is not available in the Sentinel workspace.
Why D: If the query in an analytics rule references a table that does not exist in the Microsoft Sentinel workspace, the rule will fail to execute or return no results, preventing incident generation. This is a common misconfiguration when migrating or authoring rules that depend on specific data connectors or schema that have not been onboarded.
Variation 2. 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?
medium- A.An automation rule is suppressing incidents with the same name.
- B.The workspace retention period is set to less than 90 days.
- C.The Log Analytics agent is not installed on the VMs.
- ✓ D.The analytics rule is enabled and the query is correctly filtering for event ID 4625.
Why D: 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.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.