SC-200 Manage a security operations environment Practice Question
You are the security analyst for a company that uses Microsoft Sentinel. You notice that a critical analytics rule has not generated any incidents in the past week, but you know that relevant logs are being ingested. You need to troubleshoot why the rule is not firing. What is the first step you should take?
⚠ Common exam trap
The trap here is that candidates often jump to checking data ingestion (Option B) even when the question states logs are being ingested, or they assume a rule reset (Option C) will fix a logic problem, missing the fundamental step of validating the query itself.
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
✓
Run the analytics rule's query directly in Log Analytics to see if it returns results.
The first step in troubleshooting a Sentinel analytics rule that is not generating incidents despite relevant logs being ingested is to run the rule's query directly in Log Analytics. This isolates whether the issue is with the query logic itself (e.g., syntax errors, time range misconfiguration, or data not matching the KQL conditions) rather than with data ingestion or rule settings. If the query returns results in Log Analytics, the problem lies elsewhere; if it returns no results, the query needs adjustment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Check the incident creation rule configuration.
Why it's wrong here
Incident creation rules in Microsoft Sentinel are designed to group or suppress alerts into incidents based on alert properties, not to generate missing incidents from analytics rule failures. If an analytics rule fires an alert but no incident appears, the incident creation rule might be misconfigured, but the first diagnostic step must confirm whether the underlying query actually returned any results. Checking incident creation configuration before validating the query could lead you to overlook a failing query or a scheduling issue.
- ✗
Verify that the log sources are connected and sending data to the workspace.
Why it's wrong here
Verifying that log sources are connected is a useful health check, but it is not the initial troubleshooting step for a missing alert because the analytics rule might simply have a query that returns zero rows due to incorrect KQL syntax, a bad time range, or a filter mismatch. Even if the workspace is receiving data, the rule may not be evaluating the correct table or the expected events. Run the query in Log Analytics first to determine whether data is actually being returned for the rule's lookback period, and only then investigate source connectivity if the query produces nothing.
- ✗
Disable and re-enable the analytics rule.
Why it's wrong here
Disabling and re-enabling an analytics rule is a brute-force restart that does not diagnose the root cause, and it may suppress or create duplicate alerts while the rule is toggled. The rule could be failing because its query is malformed, its schedule is set incorrectly, or its data source has gaps, and a restart will not correct any of those underlying issues. Additionally, if the rule did fire an alert but incident creation failed, re-enabling will not retroactively create the missing incident; you need to inspect the rule's run history and query first.
- ✓
Run the analytics rule's query directly in Log Analytics to see if it returns results.
Why this is correct
Running the analytics rule's KQL query directly in Log Analytics is the correct first step because it isolates whether the problem lies in the rule logic or in the downstream alert/incident pipeline. By executing the exact query with the same time range and filters, you can see if any rows are returned; if none are, the rule will never fire regardless of its other settings. If the query does return data, then you should examine the rule's alert creation, incident settings, and run history. This approach provides concrete evidence and prevents you from blindly altering configuration.
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 →
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.