Manage a security operations environment →mediumMultiple Choice

SC-200 Manage a security operations environment Practice Question

You are a Microsoft Sentinel administrator for a company that ingests Microsoft Defender XDR incidents into Microsoft Sentinel. You create an automation rule to automatically assign incidents to a specific analyst. The rule uses the condition 'Analytics rule name contains 'Suspicious'' and the action 'Assign owner'. After deployment, you notice that incidents from Microsoft Defender XDR are not being assigned. What is the most likely cause?

⚠ Common exam trap

The trap here is assuming that all incidents have the same properties, when in fact incidents from different sources may lack certain fields like 'Analytics rule name'.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The condition 'Analytics rule name' is not populated for incidents that originate from Microsoft Defender XDR, so the rule condition never matches.

The automation rule failed because incidents from Microsoft Defender XDR do not have an 'Analytics rule name' property. That property is only set for incidents created by Sentinel analytics rules. To assign these incidents, the condition should be based on a property that exists, such as 'Product name' or 'Title'. This is a common pitfall when mixing incidents from different sources.

Answer analysis

Option-by-option breakdown

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

✗
Automation rules in Microsoft Sentinel can only be triggered by incidents created by analytics rules, not by incidents ingested from Microsoft Defender XDR.
Why it's wrong here
Automation rules in Microsoft Sentinel can trigger on any incident, including those created from Microsoft Defender XDR. They support conditions based on incident properties such as title, severity, and status. The limitation described is incorrect. The issue is more likely due to the specific condition used in the rule, which may not match the incident properties generated by Defender XDR.
✗
The automation rule must be enabled for each Microsoft Defender XDR connector separately.
Why it's wrong here
Automation rules are scoped to the Microsoft Sentinel workspace and apply to all incidents regardless of the connector. There is no per-connector enablement. Once the rule is enabled, it evaluates all incidents in the workspace. The issue is not about enabling the rule for a specific connector but about the condition not matching the incident properties.
✗
Automation rules require a playbook to be attached to perform the assignment action.
Why it's wrong here
Automation rules have a built-in 'Assign owner' action that does not require a playbook. Playbooks are used for more complex actions that require Logic Apps. The assignment action is native and can be configured directly within the automation rule. Therefore, the absence of a playbook is not the cause of the failure.
✓
The condition 'Analytics rule name' is not populated for incidents that originate from Microsoft Defender XDR, so the rule condition never matches.
Why this is correct
Incidents created by Microsoft Defender XDR integration do not have an associated analytics rule name because they are not generated by a Sentinel analytics rule. The 'Analytics rule name' property is only populated for incidents created by scheduled or near-real-time analytics rules. Therefore, the condition fails to match, and the assignment action never executes. Using a condition like 'Product name' or 'Title' would be appropriate instead.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question