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.

• ✗

  Enable VNet peering gateway transit and allow forwarded traffic.

  Why it's wrong here

  Enabling VNet peering gateway transit and allowing forwarded traffic in the hub-spoke topology permits spokes to use the hub's VPN/ExpressRoute gateway and allows traffic to be forwarded between peered networks, but it does not insert the Azure Firewall into the data path. Without user-defined routes that explicitly set the firewall's private IP as the next hop for inter-spoke traffic, packets flow directly across the peering connection, so no inspection or filtering occurs. This setting is necessary for certain hybrid routing scenarios but is not sufficient for forced tunneling through the central firewall.

• ✗

  Deploy a VPN gateway in each spoke and configure site-to-site VPNs to the hub.

  Why it's wrong here

  Deploying a VPN gateway in every spoke and configuring site-to-site VPN tunnels to the hub creates an over-engineered mesh that is costly and adds unnecessary latency, but the fundamental flaw is that VPN gateways are not stateful inspection devices—they only encapsulate and decrypt traffic. Even with the tunnels in place, you would still need UDRs to direct the decrypted traffic to the Azure Firewall for inspection, and the VPN gateway itself cannot enforce application-layer policies or log flows. This approach is reserved for extending on-premises networks, not for inter-spoke security within Azure.

• ✓

  Define user-defined routes (UDRs) in each spoke that direct inter-spoke traffic to the Azure Firewall in the hub.

  Why this is correct

  Defining user-defined routes (UDRs) on each spoke subnet whose address prefix covers the other spoke's address space and whose next hop is the Azure Firewall's private IP address ensures that any inter-spoke traffic is forced to traverse the hub firewall for inspection and policy enforcement. This is the canonical pattern for a hub-spoke architecture with forced tunneling, as the route table overrides the default system routes that would otherwise use the direct peering path. The firewall's network and application rules then filter, log, and optionally forward the traffic to the destination spoke.

• ✗

  Configure network security groups (NSGs) on each spoke subnet.

  Why it's wrong here

  Configuring network security groups (NSGs) on the spoke subnets can filter traffic by source/destination IP, port, and protocol, and NSGs are stateful, but they are evaluated only at the subnet or NIC boundary—they do not influence the routing path. Inter-spoke traffic would still traverse the direct peering connection without visiting the firewall; NSGs are therefore a complementary security control, not a mechanism to centralize inspection. To force routing through the hub firewall, UDRs are required, making NSG-only configuration insufficient for the stated requirement.

Go deeper

Related to this question