SC-200 Respond to security incidents Practice Question
Your organization uses Microsoft Sentinel. A new analytics rule is needed to detect brute-force attacks against your Azure SQL databases. The rule should minimize false positives and trigger only when multiple failed logins occur from a single IP address within a short time window. Which THREE components are essential for building this rule?
⚠ Common exam trap
Test-takers frequently think a watchlist of known malicious IPs (option E) is necessary for detection, but brute-force rules should detect patterns from any IP, not just pre-listed ones, and the SQLInsights table (option B) is a distractor because its name sounds relevant but it lacks authentication event data.
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
✓
An alert threshold set to trigger when the count exceeds 10 failed attempts in 5 minutes.
Setting an alert threshold to trigger when the count exceeds 10 failed attempts in 5 minutes directly reduces false positives by requiring a meaningful number of failures before alerting. This threshold aligns with common brute-force detection patterns, ensuring the rule only fires when there is a high likelihood of an actual attack rather than occasional user errors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
An alert threshold set to trigger when the count exceeds 10 failed attempts in 5 minutes.
Why this is correct
This threshold is a critical component of the rule's alert trigger condition because requiring more than 10 failed sign-ins within a 5-minute window filters out isolated, routine authentication errors while still catching high-volume brute-force patterns. In Sentinel, this is configured in the Threshold field of the analytics rule, and it complements the KQL aggregation by determining when the query's aggregate results should actually generate an incident.
- ✗
A reference to the SQLInsights table for performance data.
Why it's wrong here
The SQLInsights table stores Azure SQL Database performance telemetry such as CPU, DTU consumption, storage IO, and query latency, not security or authentication audit data. Querying it would return resource utilization metrics and therefore could never identify failed login attempts, making it useless for a brute-force detection rule. Security audit events, including LOGIN_FAILED, are instead routed to the AzureDiagnostics table when SQL auditing is enabled.
- ✓
A summarize operator in KQL to count failed login attempts per IP address within a timebin.
Why this is correct
Using the summarize operator with count() over a timebin—for example, summarize Failures = count() by SourceIP, bin(TimeGenerated, 5m)—groups all failed login events by originating IP address within each 5-minute window. This per-IP aggregation is what allows the rule to identify a single attacker making many failed attempts, rather than simply noticing a general increase in Azure SQL authentication failures across all clients. The resulting AggregatedValue is then compared against the alert threshold.
- ✓
A KQL query against the AzureDiagnostics table filtering for failed login events.
Why this is correct
The AzureDiagnostics table is the target source for Azure SQL audit logs when diagnostic settings are configured to send SQLSecurityAuditEvents to Log Analytics. Filtering on OperationName == 'SQLSecurityAuditEvents' and action_name == 'LOGIN_FAILED' restricts the query to only failed login attempts, which is the necessary event-type filter for a brute-force detection rule. Without this filter, the query would be too broad and would include successful logins and unrelated database activity.
- ✗
A watchlist containing known malicious IP addresses.
Why it's wrong here
A watchlist containing known malicious IP addresses is not required to detect a brute-force attack because the rule should generate alerts for any source IP that exceeds the failed-attempt threshold, regardless of whether that IP is already known. Watchlists serve as a supplementary data source for enrichment, such as prioritizing incidents that involve confirmed threat intelligence, or for including/excluding specific IPs in the rule's scope. Relying on a static list would miss novel attackers and is therefore not a core component of the query logic.
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.