AZ-500 Secure networking Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Allow HTTPS from App subnet priority 100, then Deny All priority 200

  Why this is correct

  This configuration is correct because Azure NSGs process rules in ascending numeric order, and priority 100 is higher than 200. The HTTPS allow rule for the App subnet is evaluated first, matching the permitted traffic, and the later DenyAll rule with priority 200 blocks all other inbound traffic. This implements the recommended pattern: a specific allow for the desired source and port, followed by a catch-all deny.

• ✗

  Deny All priority 100, then Allow HTTPS from App subnet priority 200

  Why it's wrong here

  This fails because the DenyAll rule at priority 100 is evaluated before any other rule, and Azure NSG processing stops at the first matching rule. Since DenyAll matches all inbound traffic to the Data subnet, the HTTPS allow rule at priority 200 is never reached, so the App subnet's HTTPS traffic is also blocked. The deny must have a higher numeric priority value (lower priority) than the allow to avoid preempting it.

• ✗

  Allow HTTPS from App subnet priority 100, and Deny All from any source priority 100 (duplicate priority)

  Why it's wrong here

  This configuration cannot be deployed because every rule in an NSG must have a unique priority number; Azure rejects a second rule with the same priority during creation or update. Even if the platform allowed duplicate priorities, having two rules at the same numeric priority would make the evaluation order ambiguous and nondeterministic. You must assign distinct numbers, such as 100 for the HTTPS allow and 200 for the DenyAll.

• ✗

  Allow HTTPS from App subnet priority 100, no other rules

  Why it's wrong here

  This is too permissive because Azure NSGs always include built-in default rules that cannot be removed, and the default AllowVNetInbound rule at priority 65000 permits all traffic between any resources in the virtual network. Without an explicit DenyAll rule at a lower numeric priority, traffic from any subnet or VM in the VNet—not just the App subnet—would be allowed into the Data subnet. The HTTPS allow only adds a specific permit; it does not override the broad default VNet allow, so least-privilege isolation is not achieved.