SC-100 Practice Question: Design solutions that align with security best practices and priorities

Answer analysis

Option-by-option breakdown

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

• ✓

  Create a custom analytics rule that uses the RiskLevel field to set severity

  Why this is correct

  Creating a custom analytics rule is the technically correct approach because analytics rules in Microsoft Sentinel evaluate telemetry at ingestion time and can dynamically assign incident severity by referencing data fields such as the RiskLevel attribute from Microsoft Entra ID Protection. By setting the Alert Severity to a value derived from RiskLevel (e.g., High if risk is medium, Higher if risk is high), the incident is created with the appropriate priority immediately, enabling efficient triage without further post-processing. This native, rule-based mapping is the only option among the listed alternatives that directly controls initial incident severity as the incident is generated from raw log data.

• ✗

  Configure an automation rule to set severity when risk is high

  Why it's wrong here

  Automation rules cannot directly ingest the dynamic user risk score from Microsoft Entra ID Protection to automatically assign an initial incident severity. While they can modify severity based on existing incident properties or specific analytics rules, they lack the direct integration to pull external risk data for initial classification. This option is tempting as automation rules are indeed used to set or adjust severity, making them suitable for post-creation modifications or assigning a static severity based on internal Sentinel data.

• ✗

  Use a watchlist to map risk levels to severity

  Why it's wrong here

  Watchlists are static, CSV-like collections of reference data used for filtering, enrichment, and correlation in query logic; they do not have a built-in mechanism to mutate incident properties or assign severity. Even if you construct a watchlist mapping risk levels to severity values, the watchlist itself is merely a lookup table and cannot execute logic to update the incident, nor is it invoked during incident creation. To leverage a watchlist dynamically, you would still need an analytics rule or automation rule to read it and apply the mapped severity, which makes this option both indirect and insufficient as a standalone solution.

• ✗

  Create a playbook that assigns severity based on risk

  Why it's wrong here

  Playbooks are designed for automated incident response actions such as sending notifications, collecting evidence, or triggering remediation steps after an incident has already been created and surfaced in Microsoft Sentinel. While a playbook can technically modify severity through an incident-update action, that modification occurs asynchronously post-creation, meaning there is a window where the incident exists with an unset or default severity, defeating the goal of prioritizing it from the moment it enters the queue. Furthermore, playbooks are not part of the initial analytics rule processing pipeline; invoking one would require an automation rule or manual trigger, adding complexity and latency that undermines real-time prioritization of high-risk incidents.

Go deeper

Related to this question