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

Your company wants to use Microsoft Defender for Cloud's just-in-time (JIT) VM access to reduce the attack surface. You have enabled JIT for a set of VMs. A security administrator reports that they cannot connect via RDP even after requesting access. What is the most likely cause?

⚠ Common exam trap

Candidates often assume JIT access automatically allows any authenticated user to connect, but in reality the source IP must be explicitly permitted in the policy, and a common mistake is to overlook the IP restriction when troubleshooting connectivity.

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 administrator's source IP address is not in the allowed list for the JIT policy.

The most likely cause is that the administrator's source IP address is not included in the allowed list for the JIT policy. When a user requests JIT access, Defender for Cloud opens the specified ports (e.g., 3389 for RDP) only to the source IP addresses that are explicitly permitted in the policy. If the administrator's IP is not in the allowed list, the request may be approved but the network security group (NSG) or Azure Firewall rule will not include that IP, resulting in a connection failure.

Answer analysis

Option-by-option breakdown

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

✗
The JIT policy is set at the subscription level and does not apply to individual VMs.
Why it's wrong here
JIT VM access in Microsoft Defender for Cloud can be enabled either at the subscription level or on an individual VM. A subscription-level policy is actually the recommended administrative pattern: it applies JIT to all eligible VMs in that scope, and you can still configure or override the settings for a specific VM. The statement is incorrect because a subscription-level policy does not prevent JIT from governing an individual VM; once the policy is applied, each VM's network security group gets the JIT rules.
✓
The administrator's source IP address is not in the allowed list for the JIT policy.
Why this is correct
The administrator's current source IP address must be included in the allowed source IP/CIDR list when a JIT access request is made. JIT creates an NSG rule that only permits traffic from the specified IP ranges, so if the admin's external IP is not among them, Defender for Cloud will reject the request or no temporary rule is created. The request also must satisfy RBAC permissions, but the source IP match is a separate, mandatory condition for the connection to be opened.
✗
The VM is not located in a region that supports JIT.
Why it's wrong here
Just-in-time VM access is not gated by Azure region availability; Microsoft Defender for Cloud supports JIT in all Azure public regions because the feature is implemented using standard NSG rules. As long as the VM has an attached NSG and the subscription is onboarded to Defender for Cloud, JIT works regardless of geographic location. This option is wrong because regional support is not a prerequisite for JIT VM access.
✗
The VM does not have the Azure VM agent installed.
Why it's wrong here
JIT VM access operates at the network layer by programmatically adding rules to an Azure network security group, so it does not require the Azure VM agent, guest extensions, or any in-guest components. The VM agent is only needed for OS-level telemetry and some Defender security features, not for network-level JIT. Since there is no dependency on the guest agent, a VM without the agent can still have a JIT policy enforced.

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