Secure networking →mediumMultiple ChoiceObjective-mapped

AZ-500 Secure networking Practice Question

A company has an Azure virtual network with a subnet that contains virtual machines. They have deployed Azure Firewall in a hub VNet and peered the spoke VNet to the hub. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP as the next hop. However, traffic from the VMs is still going directly to the internet. What is the most likely cause?

⚠ Common exam trap

Candidates often assume that simply creating a route table with a default route to the firewall is sufficient, but they overlook the critical step of associating that route table with the subnet, which is a separate action in the Azure portal or via PowerShell/CLI.

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 route table is not associated with the subnet.

The most likely cause is that the route table containing the default route (0.0.0.0/0) with the Azure Firewall's private IP as the next hop has not been associated with the spoke subnet. Without this association, the subnet's VMs will use the system default route, which sends internet-bound traffic directly out via the Azure default gateway (0.0.0.0/0, next hop type Internet), bypassing the firewall entirely.

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 route table is not associated with the subnet.
Why this is correct
Correct. A route table only influences traffic after it is associated with a subnet. Without that association, the subnet's effective routes remain the system defaults, so internet-bound traffic bypasses the Azure Firewall and egresses directly via the virtual NIC's default SNAT. The forced-tunneling UDR must be attached to the specific spoke subnet to redirect its default route to the firewall's private IP.
✗
The Azure Firewall's private IP is not configured as the next hop; it should be the public IP.
Why it's wrong here
Incorrect. Forced tunneling requires the next hop to be the Azure Firewall's private IP address, not its public IP. A public IP cannot be used as a next hop in a user-defined route; the next hop must be a routable private IP of a virtual appliance. Setting the next hop to a public IP would not direct traffic into the firewall's inspection pipeline and is not how forced tunneling is configured.
✗
The VNet peering is not configured correctly.
Why it's wrong here
Incorrect. If the VNet peering were misconfigured, the spoke subnet would be unable to send traffic to the Azure Firewall's private IP in the hub VNet, but the observed symptom is that internet traffic works while bypassing the firewall. That indicates peering connectivity is present and the problem lies instead in the spoke subnet's effective routing, which is controlled by route-table association, not by peering alone.
✗
The Azure Firewall has a default route that bypasses itself.
Why it's wrong here
Incorrect. The Azure Firewall is a managed service and does not have user-configurable internal routes that would cause spoke traffic to bypass itself. Its own default route governs outbound traffic from the firewall, not the forwarding decision made by the spoke subnet. The bypass occurs because the spoke subnet's route table is absent or unattached, so the default system route sends internet traffic directly instead of to the firewall.

Visual reference

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question