4.3 - VNet peering, Azure Bastion and VPN gateways
AZ-104 objective 4.3 covers connecting virtual networks and reaching VMs securely. VNet peering joins two VNets, even across regions or across different Microsoft Entra tenants, privately over the Microsoft backbone, but peering is not transitive: if VNet A peers with a hub and the hub peers with VNet B, A cannot reach B by default unless you enable gateway transit or add a direct peering. The most common reason peered traffic still does not flow is that the peering link was created on only one side. Azure Bastion provides browser-based RDP and SSH to your VMs without needing a public IP address on the VM, and it must be deployed into a dedicated subnet named exactly AzureBastionSubnet. For hybrid connectivity, a VPN gateway carries both site-to-site and point-to-site tunnels using the same VPN gateway resource on the Azure side; a route-based (dynamic) gateway is required to run BGP and connect multiple on-premises sites, and a point-to-site connection can authenticate its users with Microsoft Entra ID. Expect scenarios that describe a cross-network or remote-access need and ask which connectivity option fits.
Peering is not transitive; create it on both sides. RDP/SSH with no public IP on the VM = Bastion in AzureBastionSubnet. BGP and multiple sites need a route-based VPN gateway. Site-to-site and point-to-site share one gateway.
Practice questions
1. Two virtual networks in the same region must communicate privately over the Azure backbone. What should you configure?
- Virtual network peering (correct answer)
- A site-to-site VPN gateway tunnel that is encrypted and routed over the public internet
- A public load balancer
- A NAT gateway
VNet peering connects two virtual networks over the Microsoft backbone with low latency and private IP connectivity, no gateways or internet needed. A VPN gateway traverses the internet, a load balancer distributes traffic, and NAT gateway provides outbound connectivity.
2. You try to peer two virtual networks whose address ranges overlap. What is the result?
- The peering cannot be established (correct answer)
- The peering succeeds and Azure silently renumbers one of the two overlapping virtual networks for you
- Traffic is automatically load balanced
- The two VNets are merged into one
VNet peering requires non-overlapping address spaces; if ranges overlap, Azure blocks the peering. It never renumbers or merges networks on your behalf.
3. VNet A is peered with a hub VNet, and the hub is peered with VNet B. By default, can A reach B through the hub?
- No, peering is not transitive (correct answer)
- Yes, because Azure automatically forwards traffic transitively across every chained peering by default
- Yes, but only for global peering
- Only if both VNets share a subnet
Peering is not transitive: A and B do not communicate through the hub just because each is peered to it. You need a hub NVA/gateway with routing, or a direct peering, to connect them.
4. You must connect two virtual networks located in two different Azure regions using private IPs. What do you configure?
- Global VNet peering (correct answer)
- A regional peering, which by definition can only connect virtual networks located in the same Azure region
- A public load balancer
- A NAT gateway
Global VNet peering links VNets in different regions over the Microsoft backbone with private IPs. Regional peering only works within one region, and load balancers or NAT gateways serve other purposes.
5. Spoke VNets must reach on-premises through the VPN gateway that lives in the hub VNet. What must you enable on the peering?
- Gateway transit and use remote gateways (correct answer)
- A separate VPN gateway deployed inside every single spoke virtual network that needs on-premises access
- A NAT gateway on each spoke
- A private endpoint per spoke
On the hub side you allow gateway transit, and on each spoke side you enable use remote gateways, so spokes share the hub's gateway instead of each deploying their own.
6. On a peering, traffic that did not originate in the peered VNet (for example forwarded by an NVA) is being dropped. What setting fixes this?
- Allow forwarded traffic (correct answer)
- Removing the network security group from every subnet so that absolutely all traffic is permitted without filtering
- Gateway transit
- A second public IP address
Allow forwarded traffic lets a VNet accept packets that were not sourced from the peered VNet itself, which is required when an NVA forwards traffic. Removing NSGs is not the intended control.