SC-200 Perform threat hunting Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Connect Microsoft 365 data sources (e.g., Office 365, Entra ID, Defender for Cloud Apps)

  Why this is correct

  Connecting Microsoft 365 data sources is essential because Microsoft Sentinel hunting queries must run against ingested telemetry from these connectors. Office 365 and Entra ID provide audit logs, sign-in logs, and email/Teams activity, and Defender for Cloud Apps adds SaaS shadow IT and session data. Without these sources, KeyVault events, IdentityInfo, and other UEBA-dependent tables remain empty, so hunting for malicious user behavior is impossible.

• ✗

  Create a Watchlist that maps user names to email addresses

  Why it's wrong here

  A watchlist that simply maps usernames to email addresses is a lightweight reference table stored in Sentinel; it can enrich a hunting query by joining on the machine-readable username, but it does not ingest any security telemetry or create baselines. Threat hunting can be performed without it, and creating one before connecting data sources is pointless because there would be no event logs to join against. It is therefore useful only as an optional enrichment aid, not an essential configuration step.

• ✓

  Enable User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel

  Why this is correct

  Enabling User and Entity Behavior Analytics (UEBA) is essential for hunting because it uses machine learning to create per-entity baselines for users, hosts, and applications, flagging deviations such as atypical sign-in times or impossible travel. UEBA populates BehaviorAnalytics tables that specialized hunting queries reference, and it must be turned on in Microsoft Sentinel settings after data sources are connected. Without UEBA, activities and user identity are correlated but lack the risk-scored behavioral anomaly context needed for proactive hunting.

• ✗

  Configure custom analytics rules for every MITRE ATT&CK technique

  Why it's wrong here

  Analytics rules are built for automated detection and alert generation, not for investigative hunting, which is interactive and query-driven. Trying to create custom rules for every MITRE ATT&CK technique is not only unnecessary but unmanageable, and Microsoft already supplies a set of analytics templates that can be enabled rather than custom-built. The essential building blocks for hunting are a solid KQL query foundation and normalized data, not an exhaustive library of detection rules.

• ✗

  Install Sysmon on all domain controllers

  Why it's wrong here

  Installing Sysmon on domain controllers is an endpoint telemetry enhancement that is not part of Microsoft Sentinel configuration setup, and it only covers a subset of identity-related infrastructure rather than the entire environment. Sysmon adds Process Creation and network connection logging, which can refine hunts for lateral movement, but it requires agent deployment, generates high volume, and is not required before baseline hunting can begin. For basic hunting, the Microsoft 365 and UEBA data sources provide sufficient behavioral signal.

Go deeper

Related to this question