Design solutions that align with security best practices and priorities →hardMultiple ChoiceObjective-mapped
SC-100 Practice Question: Design solutions that align with security best practices and priorities
Your organization uses Microsoft Sentinel and has deployed the Analytics rule 'TI map IP entity to AzureActivity' to detect suspicious activities based on threat intelligence. The SOC team reports that the rule has a high false positive rate because it matches benign IP addresses used by legitimate services. What design change should you recommend to reduce false positives while maintaining detection coverage?
⚠ Common exam trap
Candidates often choose Option D, thinking a separate suppression rule is needed, but Microsoft Sentinel's analytics rules support direct exclusion via watchlists in the query logic, making a separate rule redundant and less reliable.
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
✓
Create a watchlist of trusted IP addresses and modify the rule to exclude those IPs.
Creating a watchlist of trusted IP addresses and modifying the TI map IP entity to AzureActivity rule to exclude those IPs directly addresses the high false positive rate caused by benign IPs. This approach preserves detection coverage for all other threat intelligence matches while filtering out known legitimate services, leveraging Sentinel's watchlist feature for dynamic exclusion without disabling the rule.
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 alert threshold to require multiple occurrences within a time window.
Why it's wrong here
Raising the alert threshold to require multiple occurrences within a time window changes the rule's frequency but does not eliminate the root cause: benign IPs that are incorrectly matched to threat intelligence. Since the same trusted source will repeatedly match the TI indicator, multiple occurrences within the window could still generate an alert, while a genuine single-event attack from a non-trusted IP might be suppressed. This effectively penalizes all activity, delaying response to real incidents and doing nothing to exclude the specific problematic IPs.
- ✗
Disable the rule and rely on manual hunting queries.
Why it's wrong here
Disabling the rule entirely removes automated detection of threat-intelligence matches on AzureActivity, leaving security analysts to manually craft hunting queries every time they want to catch such activity. Manual hunting is reactive, unscheduled, and easily overlooked in high-volume environments; Sentinel loses its continuous monitoring guarantee, and the organization becomes dependent on analyst availability and vigilance. Moreover, even if hunting queries are run, they will still yield the same false positives unless they also exclude trusted IPs, so this option neither improves accuracy nor maintains baseline coverage.
- ✓
Create a watchlist of trusted IP addresses and modify the rule to exclude those IPs.
Why this is correct
Creating a watchlist of trusted IP addresses and modifying the rule to exclude those IPs directly addresses the source of the false positives without disabling detection. In Sentinel, you can build a watchlist (e.g., via CSV or PowerShell) and then reference it in the analytics rule's KQL query using the `_GetWatchlist` function—for instance, adding a `where IPAddress !in (_GetWatchlist('TrustedIPs'))` clause. This keeps the rule active for all other IPs, ensuring genuine threat-intelligence matches still generate alerts while known benign entities are filtered out, and it allows easy updates to the trusted list without re-editing the rule each time.
- ✗
Create a separate analytics rule that suppresses alerts when the source IP is in a trusted list.
Why it's wrong here
Creating a separate suppression rule is inefficient as the original 'TI map IP entity to AzureActivity' rule would still generate alerts for benign IPs, only for them to be subsequently suppressed. This adds unnecessary processing overhead and noise before the suppression mechanism activates. This option is tempting because alert suppression is a valid Sentinel feature for managing noise from built-in rules that cannot be directly modified, or for specific, known benign activities like planned security tests that you wish to acknowledge but not action.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-100 question from scratch — 208 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-100 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-100 exam.