SC-200 Manage a security operations environment 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.

• ✗

  Use a logic app trigger to change severity

  Why it's wrong here

  Using a logic app trigger is incorrect because Sentinel's native automation rules can directly configure incident assignment and override severity based on the originating analytics rule *at the point of incident creation*. Logic apps are powerful for custom, complex automation workflows, such as integrating with external systems, performing multi-step remediation, or applying conditional logic beyond simple property matching, making them tempting for general automation needs. However, for this specific requirement of initial assignment and severity setting, Sentinel's built-in automation rule functionality is the direct and intended mechanism.

• ✗

  Create a playbook to modify the incident properties

  Why it's wrong here

  A playbook could technically modify incident properties via the Microsoft Sentinel API, but it requires creating and managing an Azure Logic Apps resource, granting it Sentinel permissions, and wiring it to an automation rule to invoke it. That adds operational overhead and latency, whereas automation rules have built-in actions that directly change incident properties with no external dependency. Moreover, a playbook runs after the incident exists, so it cannot influence property values at the moment of incident creation unless you also set up a complementary automation rule to trigger it.

• ✗

  Create a separate analytics rule to override the incident

  Why it's wrong here

  Analytics rules are designed to generate alerts and create incidents when query conditions are met; they do not have any capability to modify an already-existing incident. Creating a separate analytics rule to 'override' the original incident would simply cause the query to fire again, producing a new, duplicate incident with its own unique incident ID and potentially different severity or owner. This would fragment the incident state, create alert fatigue, and undermine the single-incident workflow you are trying to achieve, rather than updating the original incident's properties.

• ✓

  Configure an automation rule with 'Add tag' and 'Set severity' actions, plus 'Assign owner'

  Why this is correct

  Automation rules in Microsoft Sentinel natively support incident property modification through actions like 'Add tag', 'Set severity', and 'Assign owner'. You can configure these rules with conditions scoped to specific analytics rules, yet they run automatically when an incident is generated or updated, so the severity and owner are set at creation time without manual intervention or external tooling. This is the recommended, built-in mechanism for incident property management, and it avoids the complexity of playbooks while also preventing duplicate incidents.

Go deeper

Related to this question