SC-200 Manage a security operations environment Practice Question
Your organization uses Microsoft Sentinel with UEBA (User and Entity Behavior Analytics) enabled. The SOC team notices that UEBA is not generating any anomalies for a specific user group. What is the most likely cause?
⚠ Common exam trap
SC-200 often tests the UEBA baseline requirement, tricking candidates into blaming missing data connectors or disabled analytics rules when the real issue is simply insufficient historical data for behavioral learning.
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
✓
The data history for that user group is less than the required baseline period.
UEBA in Microsoft Sentinel requires a baseline period of historical data (typically 14 days minimum, often up to 30 days) before it can establish normal behavior patterns and generate meaningful anomalies. If a user group was recently added or their identity data has only been ingested for a short time, Sentinel lacks the behavioral baseline needed to flag deviations, so no anomalies appear. This is expected behavior, not a misconfiguration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The user group is excluded from Identity Protection.
Why it's wrong here
Microsoft Entra ID Protection exclusions govern risk detections surfaced there, not Sentinel UEBA baselines, which are computed from Sentinel-ingested logs. It is tempting because excluding a group from risk policies does suppress identity risk signals, and would be correct if the missing output were Entra ID Protection risk detections.
- ✓
The data history for that user group is less than the required baseline period.
Why this is correct
UEBA builds behavioural baselines from historical activity before it can flag deviations. A user group with insufficient data history has no established normal pattern, so the analytics engine cannot compute anomalies for it regardless of connector health or licensing state.
- ✗
The user group is not being monitored by any data connector.
Why it's wrong here
UEBA builds behavioural baselines from ingested logs, so a group whose activity arrives through no connector produces no identity or sign-in events to analyse. It is tempting because connector gaps genuinely cause missing data, but the stem states UEBA is enabled and other groups do generate anomalies.
- ✗
The analytics rules for UEBA are not enabled.
Why it's wrong here
UEBA anomaly detection runs from its own configuration and data sources, not from analytics rules, which generate incidents and alerts from scheduled or near-real-time queries. It is tempting because disabled rules do suppress alerting, and would be correct if the SOC reported missing incidents rather than missing anomalies.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.