Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel →easyMultiple Choice

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

A security analyst receives a high-severity alert in Microsoft Sentinel indicating a potential brute-force attack against an Azure VM. The analyst wants to automatically block the attacker IP for 24 hours. What is the most efficient way to achieve this?

⚠ Common exam trap

Watch out — candidates often confuse Azure Policy (which is for compliance and governance) with NSG rules (which are for network traffic control), or mistakenly think Just-in-Time VM access can block a specific IP, when it only manages port access timing.

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 Sentinel that runs a playbook to add a deny NSG rule.

It leverages Microsoft Sentinel's automation rules to trigger a playbook that programmatically adds a deny Network Security Group (NSG) rule, blocking the attacker's IP for a specified duration. This is the most efficient approach as it automates the response without manual intervention, directly modifying the NSG attached to the VM's subnet to drop inbound traffic from the malicious IP.

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 Sentinel that runs a playbook to add a deny NSG rule.
Why this is correct
An automation rule in Microsoft Sentinel triggers a playbook—a Logic Apps workflow—that can programmatically add a deny rule to the network security group (NSG) attached to the VM's subnet, blocking the attacker's source IP. This provides immediate and consistent containment without manual intervention, making it the correct response for a high-severity alert requiring rapid network-level blocking.
✗
Enable Just-in-Time VM access to restrict all RDP traffic.
Why it's wrong here
Just-in-Time (JIT) VM access restricts RDP connections by opening ports only for specific approved users and for a limited duration, but it does not block a specific attacker IP—it governs who can connect, not which source addresses are denied. An already authorized user or an existing open port would still allow the attacker's traffic, and JIT is a preventive access control rather than an incident-response action.
✗
Create an Azure Policy to deny all traffic from the attacker IP.
Why it's wrong here
Azure Policy is a governance tool that audits or enforces resource configuration compliance, such as requiring certain tags or NSG rules, but it evaluates resources only during deployment and periodic compliance checks—not in real time for network traffic. You cannot use Azure Policy to block a specific IP address at runtime, as it cannot see or react to packet-level alert events, so it is unsuitable for immediate, automatic threat blocking.
✗
Manually add a deny rule to the NSG attached to the VM's subnet.
Why it's wrong here
Manually adding a deny rule to the NSG attached to the VM's subnet is a valid containment action, but it relies on a human analyst, introducing latency and potential error during a high-severity incident. Unlike an automation rule that invokes a playbook, this manual process does not scale and cannot provide an immediate, consistent response, so it fails to meet the requirement for an automated security response.

Visual reference

Go deeper

AZ-500 Practice Question: Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel

Why each option matters

Option-by-option breakdown

Related to this question