Manage identity and access →mediumMultiple ChoiceObjective-mapped

AZ-500 Manage identity and access Practice Question

A security operations team uses Microsoft Sentinel. They want to create an automation that automatically changes the severity of an incident from 'Medium' to 'High' when a specific indicator of compromise (IOC) is observed in the incident's entities. The playbook should run immediately when the incident is created. Which type of automation rule trigger should they configure?

⚠ Common exam trap

Many exam-takers confuse 'When alert is generated' with incident creation, not realizing that alerts are raw signals and incidents are the correlated case that can have severity changed, leading them to pick Option C instead of A.

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

✓

When incident is created

The requirement specifies that the automation should run immediately when the incident is created. In Microsoft Sentinel, an automation rule with the trigger 'When incident is created' executes a playbook as soon as the incident is generated, before any updates occur. This allows the playbook to evaluate the incident's entities (e.g., IP addresses, hashes) and change the severity from 'Medium' to 'High' if a specific IOC is present, meeting the real-time response need.

Answer analysis

Option-by-option breakdown

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

✓
When incident is created
Why this is correct
The "When incident is created" trigger is an automation rule trigger that fires the moment Microsoft Sentinel generates a new incident, either from an alert or through manual creation. This trigger enables a playbook to begin executing immediately, allowing security teams to perform instant triage, enrichment, or containment actions. It is the only trigger that guarantees execution exactly on incident creation, which is why it is the correct choice for this requirement.
✗
When incident is updated
Why it's wrong here
The "When incident is updated" trigger fires when an existing incident is modified, such as when it is assigned, commented on, or has its severity changed. Because this trigger does not fire at initial creation, using it would mean the playbook runs only after some subsequent update, introducing latency and failing to meet the requirement for immediate action. Therefore it is incorrect for automating responses to newly created incidents.
✗
When alert is generated
Why it's wrong here
The "When alert is generated" trigger is designed for alert-level automation, not incident-level automation. Microsoft Sentinel incidents often aggregate multiple alerts into a single incident, so triggering on alert generation can cause a playbook to run multiple times for correlated alerts and without the incident context. Since the requirement explicitly targets incident creation, this trigger is not appropriate.
✗
Scheduled
Why it's wrong here
The "Scheduled" option refers to the frequency for running analytics rules that execute periodic KQL queries, not a valid trigger for automation rules. Automation rules in Microsoft Sentinel only support the "When incident is created" and "When incident is updated" triggers; "Scheduled" is unavailable in that context. Consequently, it cannot be used to execute a playbook on incident creation.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question