Troubleshooting Analytics Rules Not Generating Incidents in Microsoft Sentinel
Exhibit
Refer to the exhibit.
```json
{
"properties": {
"displayName": "Sensitive Data Access Alert",
"severity": "Medium",
"query": "OfficeActivity | where Operation == 'FileAccessed' and UserAgent contains 'Microsoft.Copilot' | project TimeGenerated, UserId, FileName",
"queryFrequency": "PT1H",
"queryPeriod": "PT1H",
"triggerOperator": "GreaterThan",
"triggerThreshold": 5
}
}
```Refer to the exhibit. You have created a scheduled analytics rule in Microsoft Sentinel as shown. The rule is not generating any incidents, even though you know Copilot for Microsoft 365 is accessing sensitive files. What is the most likely cause?
Quick Answer
The answer is that the table being queried does not contain Copilot events. This is the most likely cause because the analytics rule is configured to query the 'SensitivityLabelEvents' table, which tracks changes to sensitivity labels but does not record Copilot for Microsoft 365 activities. Copilot events are stored in the 'MicrosoftCopilotAudit' table, or can be found in 'CloudAppEvents' with specific filters, so the rule’s query returns zero matching records and fails to generate incidents. On the SC-200 exam, this scenario tests your ability to match the correct data source to the threat you are investigating—a common trap is assuming all audit data lives in one table. Remember the memory tip: “Copilot chats land in CopilotAudit, not in label edits.”
⚠ Common exam trap
Watch out — candidates often assume any table related to sensitivity labels will contain all Copilot events, but Microsoft separates Copilot-specific audit logs into a dedicated table, and the exam tests awareness of this schema distinction.
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 being queried does not contain Copilot events
The rule queries the 'SensitivityLabelEvents' table, which tracks sensitivity label changes but does not contain Copilot for Microsoft 365 events. Copilot events are stored in the 'MicrosoftCopilotAudit' table (or 'CloudAppEvents' with specific filters). Since the query targets the wrong table, no matching records are returned, and no incidents are generated.
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 triggerThreshold is too high
Why it's wrong here
Threshold might be fine, but data is missing.
- ✓
The table being queried does not contain Copilot events
Why this is correct
Copilot events are in CloudAppEvents.
- ✗
The severity is set to Medium, which suppresses incidents
Why it's wrong here
Severity does not suppress incidents.
- ✗
The queryFrequency is too short
Why it's wrong here
Frequency is reasonable; the issue is the data source.
Go deeper
Related to this question
About these practice questions
One of 209 original SC-200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 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 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.
Variation 2. 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 3. 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?
medium- A.The queryPeriod and queryFrequency are the same, causing overlapping windows.
- B.The triggerThreshold is set to 0, which should always trigger.
- C.The ARM template is missing the required 'kind' property.
- ✓ D.The table DeviceEvents is not ingested into the Log Analytics workspace.
Why D: 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.
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.