4 of the 12 questions we have for this objective, shown with the answer and the reasoning.
Design and implement VNet connectivity and routing
Holloway Systems has vnet-prod (10.60.0.0/16) with a VPN gateway that learns routes from on-premises over BGP, including 172.16.0.0/12 and a default route 0.0.0.0/0. A network virtual appliance (NVA) at 10.60.250.4 inspects traffic. The route table rt-app on subnet snet-app contains: 172.16.0.0/12 next hop Virtual appliance 10.60.250.4; 0.0.0.0/0 next hop Virtual appliance 10.60.250.4; gateway route propagation is enabled. A VM in snet-app sends a packet to 172.16.5.10 and another to 8.8.8.8.
Which next hop does Azure use for each destination?
- A172.16.5.10 goes to the virtual appliance 10.60.250.4; 8.8.8.8 goes to the virtual appliance 10.60.250.4.For both destinations the longest matching prefix is identical between the UDR and the BGP route (172.16.0.0/12 and 0.0.0.0/0 respectively), and when prefixes tie a user-defined route takes precedence over a BGP route. Both packets go to the NVA.
- B172.16.5.10 goes to the virtual network gateway; 8.8.8.8 goes to the virtual appliance 10.60.250.4.The BGP route 172.16.0.0/12 has the same prefix length as the UDR, and a UDR wins that tie, so the on-premises destination also goes to the NVA.
- C172.16.5.10 goes to the virtual network gateway; 8.8.8.8 goes to the virtual network gateway.This would be the result only if gateway route propagation were enabled and no UDRs existed. The UDRs override both BGP routes.
- D172.16.5.10 goes to the virtual appliance 10.60.250.4; 8.8.8.8 goes to the Internet.The system route for 0.0.0.0/0 to Internet is overridden by the UDR for 0.0.0.0/0 to the NVA; system routes have the lowest priority when prefixes tie.
Why: Azure route selection is a two-step rule: pick the longest matching prefix, and if several routes share that prefix, prefer user-defined routes, then BGP routes, then system routes. In this scenario the UDRs deliberately duplicate the prefixes learned from on-premises so that the NVA sits in the path for both on-premises and internet traffic, and the tie-break guarantees the NVA wins. If the team had instead wanted on-premises traffic to bypass the NVA they would remove the 172.16.0.0/12 UDR; if they wanted to stop BGP routes from reaching the subnet at all they would disable gateway route propagation on the route table. Diagnosing these cases is done with the effective routes view on the NIC.
Design and implement VNet connectivity and routing
Birchwood Retail has vnet-east (10.10.0.0/16) in East US in subscription Sub-A and vnet-west (10.20.0.0/16) in West US in subscription Sub-B. Both subscriptions are in the same Microsoft Entra tenant. An administrator with Network Contributor on vnet-east created a peering from vnet-east to vnet-west; the peering status shows Initiated and VMs cannot communicate. The company wants VMs in both networks to communicate privately with the least additional cost.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate the reciprocal peering from vnet-west to vnet-east in Sub-B so that both peering links reach the Connected state.Peering is a pair of links, one on each virtual network. Initiated means only one side exists; the status changes to Connected after the matching peering is created on the other network.
- BGrant the administrator the Network Contributor role (or a custom role with Microsoft.Network/virtualNetworks/peer/action) on vnet-west.Creating the reciprocal link requires permission on the second virtual network. Cross-subscription peering works in the same tenant as long as the identity has rights on both networks.
- CDeploy a VPN gateway in each virtual network and create a VNet-to-VNet connection.VNet-to-VNet VPN works but adds two gateways with hourly charges and lower throughput; global peering is cheaper and simpler for private connectivity between regions.
- DChange the address space of vnet-west to 10.10.0.0/16 so that both networks use the same range.Peered virtual networks must have non-overlapping address spaces. Making them identical would prevent the peering from being created at all.
- EEnable Allow gateway transit on the vnet-east peering so that traffic can flow to vnet-west.Gateway transit shares a VPN or ExpressRoute gateway with a peer; neither network has a gateway, and the setting does not affect basic VM-to-VM connectivity.
Why: A virtual network peering is only complete when both virtual networks have a peering resource pointing at each other; until then the status is Initiated and no traffic flows. The two networks here are in different regions and different subscriptions, which is fully supported as global peering within a tenant, but the administrator needs rights on both networks to create the second link. The deciding constraint is least cost, so the VPN gateway alternative is wrong even though it would work. Overlapping address spaces block peering rather than enabling it, and gateway transit is irrelevant when no gateway exists.
Design and implement VNet connectivity and routing
Thornfield Data runs 80 virtual machines in snet-workers (10.15.2.0/24) behind an internal Standard load balancer with no public IP. The VMs call a third-party API that allow-lists source addresses and they frequently fail with connection timeouts; Azure Monitor shows SNAT port exhaustion on the VMs' default outbound access. The security team forbids assigning public IP addresses to VMs, and the solution must provide a predictable set of outbound addresses with minimal administrative effort.
What should you recommend?
- ADeploy an Azure NAT Gateway with a public IP prefix and associate it with snet-workers.NAT Gateway provides outbound-only connectivity for a whole subnet with up to 64,512 SNAT ports per public IP, a predictable set of addresses from the prefix, and no public IPs on the VMs. It is the recommended fix for SNAT exhaustion.
- BAssign a Standard public IP address to each virtual machine so that each has its own SNAT ports.This resolves exhaustion but violates the rule against public IPs on VMs and gives the third party 80 addresses to allow-list.
- CConvert the internal load balancer to a public Standard load balancer and configure outbound rules with manual port allocation.Outbound rules work, but they require a public frontend, careful per-VM port allocation and ongoing tuning as the pool grows; NAT Gateway is the lower-effort, higher-capacity option.
- DDeploy Azure Firewall in the subnet and route the API traffic through it.Azure Firewall can SNAT outbound traffic, but it is a far more expensive inspection service and still needs its own dedicated subnet and routes; it is not the appropriate tool when the requirement is only outbound address translation.
Why: Azure NAT Gateway is the purpose-built answer for outbound-only internet connectivity from a subnet. It replaces default outbound access and load balancer outbound rules, dynamically allocates SNAT ports across all VMs in the subnet, and scales to 16 public IPs or a /28 prefix for more than a million ports. The deciding constraints here are no public IPs on VMs, predictable source addresses and minimal effort, which together point to NAT Gateway rather than per-VM IPs or outbound rules. Azure Firewall is a security product; using it purely for SNAT is over-engineering and over-spending. Remember NAT Gateway never handles inbound traffic.
Design and implement VNet connectivity and routing
Elmcroft Analytics reports that VM vm-etl01 (10.30.4.5) in snet-etl can no longer reach the on-premises data warehouse at 172.20.8.15 after a firewall was added to the hub. The subnet has route table rt-etl containing 0.0.0.0/0 next hop Virtual appliance 10.0.3.4 and 172.20.0.0/16 next hop Virtual appliance 10.0.3.4. In Network Watcher, Next hop for source 10.30.4.5 and destination 172.20.8.15 returns next hop type None. The firewall VM at 10.0.3.4 is running, and an NSG test with IP flow verify returns Allow.
What is the most likely cause?
- AThe virtual appliance address 10.0.3.4 is in the peered hub, and Allow forwarded traffic or the peering itself is not configured, so Azure has no valid path to the next hop and returns None.A missing peering would make the firewall unreachable, but Next hop would still report Virtual appliance with 10.0.3.4 as the next hop IP, because the UDR is the matching route. It would not return None.
- Brt-etl also contains a more specific route, such as 172.20.8.0/24, with next hop type None, and by longest prefix match it is the effective route for 172.20.8.15.A Next hop result of None means the route that matched the destination has next hop None. A longer prefix such as 172.20.8.0/24 to None beats the 172.20.0.0/16 UDR to the appliance and black-holes the traffic. Effective routes on the NIC of vm-etl01 show exactly which route matched.
- CThe NSG on snet-etl is blocking outbound traffic to 172.20.8.15.IP flow verify already returned Allow for the flow, and NSG evaluation is separate from route selection; an NSG block would not change the Next hop result.
- DThe firewall VM has IP forwarding disabled on its NIC, which causes Azure to report the next hop as None.IP forwarding affects whether the NVA accepts packets destined elsewhere; it does not change what the Next hop tool reports for the source VM, which would still show Virtual appliance.
Why: Network Watcher's Next hop tool evaluates the effective route table of the source NIC and reports which route matched and where it points. A result of None means the matching route has next hop None, so the platform drops the packet before any NSG or appliance is involved. Because rt-etl has a 172.20.0.0/16 UDR pointing at the appliance, the only way to get None for 172.20.8.15 is a longer-prefix route to None that wins by longest prefix match, often a leftover black-hole route added during the firewall change. The disciplined diagnosis is to open Effective routes on the NIC, find the route Azure actually selected for 172.20.8.15, and correct or remove it. Peering problems, NSGs and IP forwarding produce different symptoms and are distractors here.