AZ-500 Show IP Route Output Practice Questions

Explanation: Disabling 'Virtual network gateway route propagation' prevents routes from the ExpressRoute gateway from being automatically added to the subnet's route table. However, the UDR with 0.0.0.0/0 only covers internet-bound traffic. Traffic destined to on-premises networks uses the specific prefix learned from ExpressRoute (e.g., 10.0.0.0/8). Even with propagation disabled, the route table does not have a route for that specific on-premises prefix. The 0.0.0.0/0 route is less specific, so traffic matching the on-premises prefix will not use it. To force on-premises traffic through the firewall, you must add an explicit UDR for the on-premises address prefix with next hop as the Azure Firewall. The Azure Firewall's location and route table association are not the issue here.

Explanation: When you associate a route table with a subnet, the effective routes are the combination of system routes and user-defined routes. If the firewall's private IP is specified as the next hop for 0.0.0.0/0, but the firewall itself is not deployed with 'Forced Tunneling' or the route table is not properly propagated, the issue is often that the route table does not have 'Propagate gateway routes' set to 'No'. However, the most common cause is that the next hop type is not set to 'Virtual appliance'. In Azure, for user-defined routes, the next hop type for a virtual appliance must be 'Virtual appliance' and the IP address must be the private IP. If they set next hop type to 'Internet', traffic will go directly to internet. So option mentioning misconfigured next hop type is correct.

Explanation: For a UDR that directs traffic to an NVA to be effective, the NVA's network interface must have IP forwarding enabled. Without IP forwarding, the NVA will drop traffic that is not destined to its own IP address, and the traffic will not be forwarded. System routes for VNet peering do not take precedence over UDRs if the UDR is more specific, but in this case the UDR is specific to VNet-A's prefix. However, if IP forwarding is not enabled, the NVA cannot forward the traffic even if the route is present. The other options are not the primary cause: the NVA is likely reachable, the UDR is on the correct subnet, and peerings do not override UDRs.

Explanation: 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.

Explanation: For an NVA to forward traffic in Azure, its network interface must have IP forwarding enabled. Without IP forwarding, the VM will drop traffic not addressed to itself. Even with correct UDRs, the NVA must be configured to forward traffic. The route table association and peering are correct, but the NVA itself must be set up to route packets.