SC-200 Manage a security operations environment Practice Question
Your organization uses Microsoft Defender XDR and has a custom detection rule that queries DeviceProcessEvents for suspicious PowerShell commands. You notice that the rule is generating a high number of false positives. You need to reduce false positives while still detecting real threats. What should you do?
⚠ Common exam trap
Watch out — candidates often think lowering severity or changing the detection technique reduces false positives, but only refining the query logic (e.g., excluding trusted signers or accounts) directly addresses the root cause of false alerts.
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
✓
Add a condition to exclude processes signed by trusted certificates or from known IT admin accounts.
Adding a condition to exclude processes signed by trusted certificates or from known IT admin accounts directly reduces false positives by filtering out legitimate administrative activity. Custom detection rules in Microsoft Defender XDR allow you to refine queries with additional conditions, such as excluding specific signers or accounts, which preserves detection of malicious PowerShell commands while ignoring benign ones.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a condition to exclude processes signed by trusted certificates or from known IT admin accounts.
Why this is correct
Adding an exclusion condition that filters out processes signed by trusted certificate publishers or running from known IT admin accounts directly targets the root cause of false positives, because many legitimate administration tools (e.g., PsExec, remote management scripts) share behavioral indicators with malicious activity. This allowlist-based approach preserves detection coverage for unsigned or anomalous processes while suppressing benign alerts that security analysts would otherwise need to triage. It is a standard tuning practice for custom detection rules in Microsoft Defender XDR.
- ✗
Disable the rule and create a new rule with a different MITRE technique.
Why it's wrong here
Disabling the rule and creating a replacement with a different MITRE technique tag is ineffective because false positives are produced by the KQL query matching benign behavioral patterns, not by the technique label assigned to the rule. The technique ID only affects reporting and mapping to the MITRE ATT&CK framework; a new rule with a different technique but the same logic will still generate the same noisy alerts. Moreover, disabling the rule entirely removes visibility into the behavior, leaving the organization blind to genuine attacks that conform to that pattern.
- ✗
Increase the lookback period from 7 to 30 days.
Why it's wrong here
Increasing the lookback period from 7 to 30 days broadens the time window that the custom detection rule examines in Microsoft Defender XDR, which typically causes the query to return more events and, therefore, more false positives, since any benign process that matched the rule in the past 30 days will also be alerted on. The lookback setting does not refine the detection logic; it simply changes the temporal scope of the data scanned, and a longer window can also degrade query performance or exceed resource limits. To reduce false positives, an analyst should adjust the query conditions or add exclusions, not extend the historical search.
- ✗
Modify the rule to set the severity to 'Informational'.
Why it's wrong here
Changing the alert severity to 'Informational' does not affect the rule's triggering logic, so the detection will still fire on the same set of benign processes and generate the same volume of alerts; only the perceived importance of those alerts changes. Informational severity causes the SOC to deprioritize or auto-suppress the alerts, which risks missing the true positive cases hiding among the noise, because the underlying matching criteria remain as broad as before. Severity is a post-detection classification, not a filtering mechanism.
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.