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 Fusion analytics rule

  Why it's wrong here

  Fusion analytics rules in Microsoft Sentinel are correlation-based detection engines that automatically combine alerts and signals from multiple sources (e.g., Microsoft Entra ID, Microsoft Defender) to create high-fidelity incidents using machine learning. They are a purely reactive detection mechanism that runs continuously in the background, not an interactive hunting method. Threat hunting, by contrast, is a proactive, analyst-driven search through raw logs to find unknown threats, so Fusion rules serve a completely different purpose.

• ✓

  Using the Hunting blade and Livestream

  Why this is correct

  The Hunting blade in Microsoft Sentinel provides a centralized interface containing built-in hunting queries mapped to MITRE ATT&CK techniques, allowing analysts to run predefined KQL searches and pivot on suspicious results. Livestream is a complementary feature that creates an ongoing KQL query session over live ingested data, presenting real-time results that update as logs flow in, with optional alerts on each result. This combination is a valid hunting approach because it directly supports proactive, iterative, and continuous investigation of workspace data.

• ✗

  Using Automation rules to trigger playbooks

  Why it's wrong here

  Automation rules are Sentinel's tool for orchestrating incident response—they define triggers, conditions, and actions such as assigning severity, closing incidents, or invoking playbooks for threat mitigation. They execute only after an incident or alert is created, making them fundamentally reactive responders rather than hunting tools. Hunting is an active, data-centric exploration process, whereas automation rules manage the lifecycle of alerts and incidents that have already been generated by detection mechanisms.

• ✓

  Using KQL queries in the Logs blade

  Why this is correct

  The Logs blade in Microsoft Sentinel (also known as the Log Analytics interface) gives analysts direct access to all raw log tables in the workspace, enabling fully custom KQL queries with joins, filtering, time-based pivots, and statistical aggregation. This allows threat hunters to test hypotheses, investigate entities, and discover patterns of suspicious behavior that scheduled queries or analytics rules may miss. As a primary interface for ad-hoc querying, the Logs blade is a valid approach to manual, iterative threat hunting.

• ✗

  Using Azure Policy to enforce compliance

  Why it's wrong here

  Azure Policy is an Azure control-plane service that enforces governance and compliance by auditing or denying resource configuration modifications, such as requiring specific tags, restricting resource locations, or ensuring standard SKUs. It does not ingest or analyze log data from workloads, nor does it have any visibility into user, entity, or network activity relevant to security threats. Therefore, using Azure Policy cannot support threat hunting in Microsoft Sentinel—it addresses infrastructure compliance, not data-plane detection or investigation.

Go deeper

Related to this question