Manage a security operations environment →mediumMultiple Select

SC-200 Manage a security operations environment Practice Question

Which TWO actions can you perform using Microsoft Sentinel automation rules?

⚠ Common exam trap

Microsoft often tests the distinction between automation rules (which act on incidents/alerts) and analytics rules (which generate incidents from log data), causing candidates to confuse the scope of automation rule actions.

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

✓

Assign an incident to a specific analyst.

Microsoft Sentinel automation rules can directly assign an incident to a specific analyst using the 'Assign owner' action. This allows security operations teams to automatically route incidents to the appropriate personnel based on criteria such as severity, tactic, or entity, improving response efficiency.

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 new analytics rule based on an incident.
Why it's wrong here
Creating a new analytics rule cannot be performed by an automation rule because analytics rules are designed for detection logic and are authored in the Analytics blade, through ARM templates, or via API. Automation rules act only after an incident has already been generated—they can adjust its state, owner, or trigger playbooks but lack any capability to create or modify detection rules that query log data.
✓
Assign an incident to a specific analyst.
Why this is correct
Assigning an incident to a specific analyst is a supported automation rule action, where you can set the owner to a particular Microsoft Entra ID user or group. This action is frequently used to implement dynamic triage and routing, such as sending all high-severity incidents to a senior threat hunter or specific incident responder as soon as the incident is created. It exists as a first-class action in the automation rule configuration pane.
✗
Modify the data connector's polling interval.
Why it's wrong here
Modifying a data connector's polling interval is not an automation rule action; connector settings are managed independently in the Data connectors page, and the polling frequency is dictated by the underlying data source, such as API throttling constraints, Log Analytics ingestion schedules, or diagnostic settings. Automation rules only execute against incidents that already exist in Sentinel and have no influence on how or when raw data is collected from external services.
✓
Run a playbook automatically when an incident is created.
Why this is correct
Running a playbook automatically when an incident is created is a core automation rule capability, because automation rules can invoke Azure Logic Apps playbooks as an action on incident creation. To be called by an automation rule, the playbook must use the Microsoft Sentinel Incident trigger and have the correct permissions to execute. This enables automated response workflows like IP blocklisting, user compromise confirmation, or enrichment from external threat intel feeds.
✗
Automatically create an incident from a log event.
Why it's wrong here
Automatically creating an incident from a log event is performed by analytics rules, not automation rules. Analytics rules run scheduled KQL queries against log data and generate alerts when thresholds are met; these alerts are then correlated into incidents by Sentinel. Automation rules trigger only after an incident has been created or updated and therefore cannot perform the underlying log-to-incident conversion or any data analysis involved in detection.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question