SC-200 Manage a security operations environment Practice Question
Your organization has a Microsoft Sentinel workspace that ingests data from Microsoft 365 Defender (Defender for Endpoint, Office 365, Identity, Cloud Apps). You have configured a scheduled analytics rule to detect possible privilege escalation based on user activity. The rule runs every 5 minutes and looks at the last 5 minutes of data. Recently, the rule has been generating a high number of false positives. You analyze the alerts and find that they are triggered by legitimate administrative actions. You need to reduce false positives without completely disabling the rule. The rule uses a KQL query that joins the IdentityLogonEvents and CloudAppEvents tables. What should you do?
⚠ Common exam trap
SC-200 often tests the difference between suppressing incidents (cosmetic) and tuning the detection query (root cause), and candidates frequently pick suppression rules because they sound like a clean fix.
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
✓
Modify the KQL query to exclude events from a list of known administrative user accounts or IP addresses.
The false positives come from legitimate administrative actions triggering a privilege-escalation detection. The most targeted fix is to refine the KQL query to exclude known administrative user accounts or IP addresses, which preserves the rule's ability to detect real privilege escalation while filtering out the noisy legitimate activity. This is the standard Sentinel tuning approach for high-fidelity detections.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the rule's run frequency to every 30 minutes.
Why it's wrong here
Raising the run frequency to every 30 minutes only shortens the interval between query executions; it does not alter the KQL matching logic that is generating the false positives. If the query still matches routine administrative activity, those matches will simply be assessed more often, potentially creating duplicate or higher-volume alerts. Frequency tuning is best reserved for issues like detection latency, not for filtering benign events.
- ✗
Reduce the query's lookback period to 1 minute.
Why it's wrong here
Reducing the lookback period to 1 minute narrows the temporal window that the query examines, but it still scans every event that occurs within that minute with the same criteria. Any known administrative user action that occurs during that short interval will still trigger the rule exactly as before, so the false positive persists while you also risk missing multi-step attack patterns that unfold over longer timeframes. The lookback should be aligned to the expected duration of the behavior being detected, not used as a blunt filter for benign actors.
- ✓
Modify the KQL query to exclude events from a list of known administrative user accounts or IP addresses.
Why this is correct
The correct approach is to refine the KQL query so that it explicitly excludes events from known administrative user accounts or IP addresses, typically using a watchlist or a static list. This removes the benign baseline activity from the detection scope while retaining coverage for non-admin users and unknown actors. Because the exclusion is part of the query logic, the rule will not generate incidents for those known safe actors, but it will still fire on unusual behavior from other principals.
- ✗
Add an incident suppression rule that closes incidents from known admin accounts.
Why it's wrong here
Incident suppression rules do not modify the analytics rule's query; they only act on incidents after they are created, automatically closing or grouping them based on properties such as account or IP. Using suppression to close incidents from known admin accounts can conceal genuine attacks if an administrator is compromised, because the incident is dismissed rather than investigated. Suppression is a case-management convenience, not a detection-tuning mechanism, and should never be a substitute for excluding known-good entities at the query level.
Go deeper
Related to this question
About these practice questions
One of 1,303 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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.