Manage identity and access →mediumMultiple Choice

AZ-500 Manage identity and access Practice Question

A security team uses Microsoft Sentinel. They want to automatically isolate a compromised virtual machine by applying a network security group (NSG) rule. They have created a playbook in Azure Logic Apps that modifies the NSG. How should they trigger this playbook when an incident of type 'Suspicious VM activity' is created?

⚠ Common exam trap

Watch out — candidates often confuse analytics rule response actions (which trigger on alert generation) with automation rules (which trigger on incident creation), leading them to incorrectly select Option C when the question explicitly requires incident-based triggering.

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

✓

Create an automation rule in Microsoft Sentinel that is triggered when an incident is created, and set the action to run the playbook.

Microsoft Sentinel automation rules are designed to trigger playbooks automatically when incidents are created, updated, or closed. By configuring an automation rule with the condition 'When incident is created' and the action 'Run playbook', the playbook that modifies the NSG will execute immediately upon the creation of a 'Suspicious VM activity' incident, achieving the desired automated isolation without manual intervention.

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 an automation rule in Microsoft Sentinel that is triggered when an incident is created, and set the action to run the playbook.
Why this is correct
This is the correct approach because automation rules are Microsoft Sentinel's native event-driven response mechanism. When an incident is created, the rule fires, evaluates conditions (such as severity, tactic, or analytics rule name), and executes a playbook as an action. This enables immediate, consistent automated response without custom code or background polling.
✗
Configure a data connector to send all alerts to the playbook.
Why it's wrong here
Data connectors are designed solely to ingest telemetry—for example, Azure Activity logs, Microsoft 365 audit logs, or third-party security products—into the Log Analytics workspace used by Sentinel. They have no mechanism to route alerts or incidents to a playbook for response; that action is outside the ingestion pipeline. Configuring a connector to 'send alerts to a playbook' is not supported and would not trigger the playbook on incident creation.
✗
Enable the playbook as a response action in the analytics rule.
Why it's wrong here
Analytics rules generate alerts and, if incident creation is enabled, create incidents, but they do not include a direct 'run playbook' configuration in the rule definition. The detection rule's scope ends at alert/incident generation; subsequent automated response must be attached via an automation rule triggered on incident creation. Although you can manually launch a playbook from an incident's action menu, this is not a built-in response action within the analytics rule itself.
✗
Use a logic app trigger that polls Sentinel incidents every minute.
Why it's wrong here
Using a Logic App with a recurrence trigger to poll Sentinel for new incidents every minute is inefficient and not event-driven. This introduces up to one minute of latency, requires custom state tracking to avoid reprocessing the same incidents, and consumes unnecessary compute resources. Automation rules are designed specifically to trigger instantly on incident creation, making polling an anti-pattern for incident response in Sentinel.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question