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.

• ✓

  Using known indicators of compromise (IOCs) from threat intelligence feeds.

  Why this is correct

  Using known IOCs such as malicious file hashes, suspicious domains, attacker IPs, and email sender addresses from threat intelligence feeds is effective because it gives the hunt concrete, evidence-backed starting points from both external intelligence and internal incident knowledge. In Microsoft Defender XDR, a hunter can run KQL queries over Advanced Hunting tables (DeviceFileEvents, DeviceNetworkEvents, EmailEvents, etc.) to cross-reference these IOCs and pivot to related processes, users, and machines. This method works best when the hunter expands beyond simple hash matches to hunt for subtle variations that preserve the attacker's underlying tradecraft.

• ✓

  Establishing a baseline of normal behavior and hunting for deviations.

  Why this is correct

  Establishing a baseline of normal behavior for users, hosts, and applications—such as typical sign-in times, PowerShell invocation patterns, or outbound traffic volumes—allows a hunter to spot statistically meaningful deviations that could indicate compromise. In Microsoft Sentinel or Defender for Endpoint, this often involves time-series analysis, percentile thresholds, or built-in UEBA features, enabling the hunter to focus on outliers rather than raw alert noise. A baseline-driven hunt is effective because it surfaces unknown threats that have no published signature and may otherwise pass through detection rules.

• ✗

  Reviewing all alerts generated by automated detection rules.

  Why it's wrong here

  Reviewing all alerts generated by automated detection rules is not proactive hunting; it is alert triage. Detection rules are inherently reactive because they encode patterns that security engineers already know to look for, so they cannot reveal novel attacker tradecraft that was never anticipated. Manual review of the full alert queue is also inefficient and noisy—most alerts are low fidelity or false positives—and does not involve the iterative hypothesis testing, raw data exploration, and context-based analysis that defines true hunting.

• ✗

  Searching for any single event that appears unusual.

  Why it's wrong here

  Searching for any single event that appears unusual is ineffective because suspiciousness in threat hunting is inherently contextual. A lone PowerShell process, a single failed sign-in, or one anomalous outbound connection is often benign, and without correlating it with adjacent events—such as process parent-child relationships, network connections, user account timestamps, or file artifacts—it lacks sufficient evidence to justify an investigation. Arbitrary single-event searches produce random noise and are not disciplined or hypothesis-driven; hunters must group and pivot across multiple tables and time windows to distinguish attacker activity from environment quirks.

• ✓

  Applying machine learning models to detect anomalous patterns.

  Why this is correct

  Applying machine learning models to detect anomalous patterns is effective because these models can characterize high-dimensional relationships and subtle correlations across millions of events, surfacing deviations that static rules or threshold-based baselines miss. In Microsoft Sentinel and Defender for Endpoint, ML-based detections (such as UEBA, impossible travel, and unusual data transfer analytics) learn the environment's normal behavior and flag activities like anomalous credential use, lateral movement, or encode-execution patterns. This expands hunting beyond known IOCs to novel or evolving threats while reducing the noise of isolated-event alerts by scoring the entire user or entity behavior.

Go deeper

Related to this question