hardmultiple choiceObjective-mapped

A company has an Azure virtual network (VNet) with multiple subnets. They deploy Azure Firewall in a hub VNet and peer spoke VNets. They want to force-tunnel all outbound traffic from a specific spoke subnet to the firewall for inspection. 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 is still bypassing the firewall. What is the most likely cause?

Question 1hardmultiple choice
Full question →

A company has an Azure virtual network (VNet) with multiple subnets. They deploy Azure Firewall in a hub VNet and peer spoke VNets. They want to force-tunnel all outbound traffic from a specific spoke subnet to the firewall for inspection. 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 is still bypassing the firewall. What is the most likely cause?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

The Azure Firewall subnet is missing a route table entry for the 0.0.0.0/0 route

The firewall subnet itself does not need a default route for spoke traffic; it needs the correct routing to send inspected traffic out. This is not the most likely cause of spoke traffic bypassing.

B

Best answer

The route table on the spoke subnet has 'Propagate gateway routes' enabled, causing a conflicting route from the hub's VPN gateway

When gateway propagation is enabled, any routes from the hub's VPN/ExpressRoute gateway are automatically added. These routes can override the custom 0.0.0.0/0 route, especially if the hub has a default route learned via VPN. Disabling propagation resolves the conflict.

C

Distractor review

The VNet peering does not allow forwarded traffic from the spoke to the firewall

Forwarded traffic is allowed by default when virtual network gateway is not used. The requirement for allowing forwarded traffic is the 'Allow virtual network gateway transit' setting in the hub and 'Use remote virtual network gateways' in the spoke, but this is for gateway transit, not for routing through a firewall instance.

D

Distractor review

The Azure Firewall is not configured with the 'Allow outbound traffic' rule

Firewall rules affect which traffic is allowed, not the routing path. Even without a rule, traffic would still reach the firewall (if routed), but be dropped. The issue is that traffic never reaches the firewall.

Common exam trap

Common exam trap: usable hosts are not the same as total addresses

Subnetting questions often tempt you into counting all addresses. In normal IPv4 subnets, the network and broadcast addresses are not usable host addresses.

Technical deep dive

How to think about this question

Subnetting questions test whether you can identify the network, broadcast address, usable range, mask and correct subnet. Slow down enough to calculate the block size correctly.

KKey Concepts to Remember

  • CIDR notation defines the prefix length.
  • Block size helps identify subnet boundaries.
  • Network and broadcast addresses are not usable hosts in normal IPv4 subnets.
  • The required host count determines the smallest suitable subnet.

TExam Day Tips

  • Write the block size before choosing the subnet.
  • Check whether the question asks for hosts, subnets or a specific address range.
  • Do not confuse /24, /25, /26 and /27 host counts.

Related practice questions

Related AZ-500 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this AZ-500 question test?

CIDR notation defines the prefix length.

What is the correct answer to this question?

The correct answer is: The route table on the spoke subnet has 'Propagate gateway routes' enabled, causing a conflicting route from the hub's VPN gateway — Azure Firewall requires that the subnet hosting it has a route table with a default route to the firewall's private IP. But for spoke subnets, if the firewall's private IP is not reachable due to the hub-spoke peering not being configured correctly, or if there is no route in the hub subnet to forward traffic back, or if the firewall subnet's route table is missing the 'AllowForwardedTraffic' attribute. The most common cause is that the 'Propagate gateway routes' setting on the spoke subnet's route table is enabled, which can inject conflicting routes (e.g., from Azure VPN Gateway or ExpressRoute) that override the custom route. Disabling 'Propagate gateway routes' ensures the custom route is used.

What should I do if I get this AZ-500 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.