SC-200 Practice Question: A SOC analyst wants to detect when a user signs…

Answer analysis

Option-by-option breakdown

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

• ✓

  Join the SigninLogs table with itself to find the earliest sign-in per user and device, then filter for those that match the earliest timestamp

  Why this is correct

  The correct logic is to derive the earliest sign-in timestamp for each user-device pair using `summarize arg_min(TimeGenerated, *) by UserId, DeviceId` and then join that summary back to the original SigninLogs table on the same user, device, and timestamp. This self-join effectively identifies only the first occurrence of a sign-in for that combination, so any row in the original table that matches the earliest timestamp for its pair is a new-device sign-in. This approach uses historical data already in the table and does not require external lists or pre-computed analytics, making it a fully self-contained and accurate detection.

• ✗

  Use the _GetWatchlist function with a custom watchlist of known user-device pairs

  Why it's wrong here

  Using `_GetWatchlist` with a custom watchlist of known user-device pairs only works if the watchlist is continuously maintained with every legitimate combination, which is impractical and prone to staleness. The watchlist lookup checks for presence of a pair, but absence from the list does not reliably indicate a new device because the watchlist might be incomplete or outdated. Moreover, this method does not inspect the historical SigninLogs to compute first-use timestamps, so it cannot answer the question 'has this device ever been used by this user before?' without external knowledge. It also introduces operational overhead for managing the watchlist, unlike the dynamic baseline derived from the table itself.

• ✗

  Use the BehaviorAnalytics table which already identifies new devices

  Why it's wrong here

  The BehaviorAnalytics table does surface UEBA-derived anomalies, some of which may relate to sign-in behavior, but relying on it here is inappropriate for several reasons. First, the scenario explicitly asks the analyst to use SigninLogs and build a detection rule themselves, so delegating to a pre-computed analytics table avoids the required query. Second, BehaviorAnalytics is generated by a separate pipeline with its own schema, latency, and retention, meaning it may not include the exact device identifiers or timestamps needed and could delay detection. Finally, BehaviorAnalytics is typically focused on aggregated risk scores and anomolies for users, not a direct per-user/per-device 'new device' flag with a raw sign-in timestamp, so it would not produce the same precise query results.

• ✗

  Apply the 'where DeviceId != '' and DeviceId startswith "device-"' filter to ensure the device is new

  Why it's wrong here

  The filter `where DeviceId != '' and DeviceId startswith "device-"` only validates that the DeviceId field is populated and follows a naming convention; it says nothing about whether that device has been seen before for that user. A user's first sign-in from a device would pass such a filter even if the device has never appeared in history, and an existing, known device could also pass it, so the filter cannot distinguish new from established devices. Additionally, many legitimate sign-ins might have empty DeviceId values or different prefix conventions, which would cause the filter to exclude valid first-time events or include repeated events. To detect new devices, you must compare each sign-in against the prior history for that user, not just inspect the string format of the device identifier.

Go deeper

Related to this question