Courseiva
← SC-200
Full test
Respond to security incidents →hardMultiple Choice

SC-200 Respond to security incidents Practice Question

Exhibit

Refer to the exhibit.

```kusto
// KQL query in Microsoft Sentinel
let threshold = 10;
let timeframe = 1h;
SigninLogs
| where TimeGenerated > ago(timeframe)
| where ResultType == "50057" // User account disabled
| summarize Count = count() by UserPrincipalName, IPAddress
| where Count > threshold
| join kind=inner (IdentityInfo | project UserPrincipalName, AccountEnabled) on UserPrincipalName
| where AccountEnabled == false
```

The KQL query above is used in a Microsoft Sentinel analytics rule. What is the purpose of this rule?

⚠ Common exam trap

Many candidates choose Option A because they see 'disabled user account' and assume any sign-in attempt is detected, but the rule requires multiple attempts (brute force pattern), not a single event.

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

✓

Detect brute force attempts against disabled user accounts.

The KQL query filters for sign-in events where the user account is disabled (e.g., StatusCode = 50057 or UserAccountControl flags indicate disabled) and then groups by source IP and user to count failed attempts over a short window. When the count exceeds a threshold, it signals a brute force attack targeting disabled accounts, which is a common post-exploitation or reconnaissance technique. Option C is correct because the rule specifically detects repeated authentication failures against disabled accounts, not just any sign-in attempt or inactivity.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Detect when a disabled user account attempts to sign in.

    Why it's wrong here

    This option is too broad. While the query does filter for disabled accounts that are attempting to sign in, it does not merely alert on any single attempt. Instead, it aggregates sign-in events by source IP address and applies a numeric threshold (e.g., count greater than a certain value), so it only triggers after multiple attempts from the same IP. That aggregation and threshold are what turn it into a pattern-based detection, not a simple 'sign-in occurred' alert, so the query would fail to catch a lone failed attempt and is not designed for that purpose.

  • ✗

    Identify users who have been disabled due to inactivity.

    Why it's wrong here

    This option misidentifies the query's intent and data source. The query operates exclusively on sign-in logs and does not inspect user account attributes such as the last successful sign-in date, the account's creation date, or the reason for disablement. It has no logic to determine if an account was disabled due to inactivity; it only evaluates whether the account is disabled at the time of the sign-in attempt and how frequently those attempts happen. Therefore, it can never distinguish between accounts disabled for security reasons, policy violations, or inactivity.

  • ✓

    Detect brute force attempts against disabled user accounts.

    Why this is correct

    This is correct because the query combines two key conditions: an account-level condition (the account is disabled) and an activity-level condition (a high count of sign-in attempts from the same source IP within a window). Repeated, high-frequency authentication attempts against disabled accounts are a hallmark of a brute-force attack, where an adversary tries many passwords against a known username without realizing the account has been deactivated. The query's aggregation by IP address and its threshold on the number of attempts filters out ordinary, low-volume failures and isolates a sustained, suspicious pattern.

  • ✗

    Monitor sign-in attempts from suspicious IP addresses.

    Why it's wrong here

    It focuses on the IP address rather than the account state. The query does not incorporate any threat-intelligence feed, IP reputation scores, or geolocation data to classify an IP as suspicious; all IPs are treated equally. The only reason an IP appears notable is the secondary effect that it generated a high count of attempts, but the primary filter is on disabled accounts. If the query were monitoring suspicious IPs, it would still detect these events even for enabled accounts, but it specifically ignores those, so the core logic is account-centric, not IP-centric.

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 →

How Courseiva writes practice questions · Editorial policy

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.