AZ-104 virtual networking explained
Implement and manage virtual networking is worth 15–20% of AZ-104, but it costs candidates more marks than its weight suggests. It covers three areas: building virtual networks and routing between them, securing access to them, and name resolution and load balancing. Questions often combine several settings in one scenario and ask why traffic does not flow.
Virtual networks and subnets
A virtual network has one or more address spaces, split into subnets. Azure reserves five addresses in every subnet: the first four and the last. A /29 therefore has eight addresses but only three usable ones. Expect at least one question that depends on that arithmetic.
Address spaces of networks you intend to connect must not overlap. Plan them before building anything; changing a used address space later is painful.
Peering
Peering connects two virtual networks over the Microsoft backbone, in the same region or across regions (global peering). Three rules come up repeatedly:
- Peering is not transitive. A peered with B and B peered with C does not connect A with C.
- Address spaces must not overlap.
- Each side has its own settings, including allowing forwarded traffic and gateway transit, which lets a spoke use a VPN gateway in the hub.
Public IP addresses
Public IPs come in SKUs. The Standard SKU is closed to inbound traffic until a network security group allows it, supports availability zones and uses static allocation. It is the SKU modern load balancers and gateways expect.
User-defined routes
Azure creates system routes automatically. A route table with user-defined routes overrides them, usually to send traffic through a firewall or network virtual appliance. Next hop types include virtual appliance, virtual network gateway, virtual network, internet and none. The most specific prefix wins. A route table does nothing until it is associated with a subnet.
Troubleshooting connectivity
Network Watcher gives you the tools: IP flow verify says whether an NSG allows a packet and which rule decided, next hop shows where a route sends it, and connection troubleshoot tests a path end to end.
Secure access to virtual networks
Network security groups
NSGs hold inbound and outbound rules with a priority from 100 to 4096. Lower numbers are evaluated first, and the first match wins. Default rules at the bottom allow traffic within the virtual network and from the load balancer, and deny everything else inbound.
An NSG can be attached to a subnet, a network interface or both. When both apply, inbound traffic is checked against the subnet NSG and then the NIC NSG; outbound in the reverse order. Traffic must be allowed by both. The effective security rules view on a NIC shows the combined result.
Application security groups let you group NICs by role, such as web or database, and use those groups as source or destination in NSG rules instead of IP addresses.
Azure Bastion
Bastion gives RDP and SSH to VMs through the browser without public IPs on the VMs. It needs its own subnet named AzureBastionSubnet, sized /26 or larger.
Service endpoints versus private endpoints
| Service endpoint | Private endpoint | |
|---|---|---|
| What it does | Extends the subnet’s identity to the service over the backbone | Gives the service a private IP in your subnet |
| Service keeps public endpoint | Yes, restricted by firewall rules | Can be disabled |
| Reachable from on-premises | No | Yes, over VPN or ExpressRoute |
| DNS changes | None | Private DNS zone needed |
When a scenario says traffic must use a private IP or be reachable from on-premises, the answer is a private endpoint.
Name resolution and load balancing
Azure DNS
Public DNS zones host your internet-facing records; the domain’s registrar must delegate to Azure’s name servers before they work. Private DNS zones resolve names inside linked virtual networks, and auto-registration creates records for VMs in a linked network automatically.
Load balancers
Azure Load Balancer works at layer 4 (TCP and UDP). A public load balancer has a public frontend IP; an internal one has a private frontend IP inside a subnet. Each needs a backend pool, a health probe and load-balancing rules. For HTTP-aware routing, such as by URL path, Application Gateway is the layer 7 option.
Troubleshooting load balancing
When backends receive no traffic, check in this order: is the health probe succeeding, does an NSG block the probe or the traffic, is the application listening on the right port, and are the VMs actually in the backend pool. Probes come from the AzureLoadBalancer service tag, which the default NSG rules allow but custom deny rules can block.
Sample questions
Question 1. You need a subnet for exactly 29 VMs, each with one private IP address, and you want the smallest possible subnet. Which prefix should you use?
- A. /28
- B. /27
- C. /26
- D. /25
Show answer
Answer: C
Azure reserves five addresses per subnet. A /27 has 32 addresses, leaving 27 usable, which is too few. A /26 has 64 addresses, leaving 59 usable, the smallest that fits 29 VMs. A /28 has only 11 usable addresses and a /25 is larger than needed.
Want more questions like this? Full AZ-104 practice tests →
Question 2. A subnet NSG allows inbound TCP 443 from the internet at priority 200. The VM's NIC has an NSG with only the default rules. HTTPS requests from the internet to the VM's public IP fail. What is the cause?
- A. Priority 200 is too high to be evaluated
- B. The NIC NSG denies the traffic with its default inbound rule
- C. The subnet needs a route table with a route to the internet
- D. The VM must be in an application security group
Show answer
Answer: B
Inbound traffic must be allowed by both the subnet NSG and the NIC NSG. The NIC NSG’s default rules deny inbound internet traffic, so the request is dropped there. Priority 200 is valid, public IPs do not need a route table, and application security groups are optional.
Want more questions like this? Full AZ-104 practice tests →
Question 3. An on-premises application connected by VPN must reach an Azure SQL database over a private IP address, and public network access to the database must be disabled. What should you configure?
- A. A service endpoint on the subnet
- B. Virtual network peering to the database
- C. Azure Bastion in the virtual network
- D. A private endpoint with a private DNS zone
Show answer
Answer: D
A private endpoint gives the database a private IP in your virtual network that on-premises clients can reach over the VPN, and lets you disable public access. A service endpoint keeps the public endpoint and does not serve on-premises traffic. Peering and Bastion do not expose a PaaS service privately.
Want more questions like this? Full AZ-104 practice tests →
What to practise
Build a hub and two spokes, peer each spoke to the hub, and prove that the spokes cannot reach each other. Add an NSG to a subnet and another to a NIC, then use IP flow verify and effective security rules until you can predict every result. Put a storage account behind a private endpoint, add Bastion, and finish with an internal load balancer whose probe you break on purpose.