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.

• ✓

  Add a user-defined route (UDR) on the spoke subnets with 0.0.0.0/0 next hop to the Azure Firewall private IP.

  Why this is correct

  A user-defined route (UDR) overrides Azure's system default route for 0.0.0.0/0, which normally sends all outbound traffic directly to the internet. By associating a route table with the spoke subnets and setting the next hop to the Azure Firewall's private IP, every packet destined outside the VNet is explicitly forwarded to the firewall for stateful inspection, logging, and policy enforcement. This also prevents asymmetric routing because the firewall's return traffic is handled separately, and the route can be propagated via BGP if needed, but a static UDR is the direct mechanism in a VNet-peered hub-and-spoke design.

• ✗

  Use service endpoints for internet-bound traffic.

  Why it's wrong here

  Service endpoints, while they improve security and routing for Azure PaaS services such as Azure Storage and Azure SQL, are not a substitute for internet egress control. They provide a direct, private connection from a subnet to a specific Azure service via the Microsoft backbone, bypassing the public internet but also bypassing any network virtual appliance like Azure Firewall. Service endpoints only apply to traffic destined to Azure service public IPs, not general internet destinations, and they do not inspect, filter, or redirect arbitrary outbound web traffic. Therefore, they fail to meet the requirement of centralizing outbound internet traffic through the firewall.

• ✗

  Enable BGP on the spoke VNets and advertise a default route from the hub.

  Why it's wrong here

  BGP is a routing protocol used to exchange routes between networks, typically over VPN gateways or ExpressRoute circuits—not across standard VNet peering. Spoke VNets do not establish BGP sessions with the hub or with Azure Firewall unless you deploy a virtual network gateway with BGP enabled and connect via VPN/ExpressRoute. Advertising a default route via BGP from the hub would, at best, influence routing for on-premises-connected networks, but it cannot insert a next hop to the Azure Firewall private IP into the spoke subnets' effective routes in a normal peering topology. Consequently, even if BGP were configured, spoke VMs would still rely on system routes or UDRs to send traffic to the firewall, making this option both impractical and incorrect for this scenario.

• ✗

  Configure the Azure Firewall to have a default route to the internet.

  Why it's wrong here

  Setting a default route to the internet on the Azure Firewall only affects the firewall's own egress path; it does nothing to redirect spoke traffic to the firewall. For traffic originating in the spoke subnets, the effective route for 0.0.0.0/0 is what matters—without a UDR that points that traffic to the firewall's private IP, the spoke's system route will send packets straight to the internet. Additionally, Azure Firewall is a managed service with fixed routing for its management and data planes; manually defining a default route on it is not a supported configuration for controlling spoke egress. This option incorrectly shifts the routing burden to the firewall instead of addressing the source subnets' route tables.

Go deeper

Related to this question