Domain 4: Implement and Manage Virtual Networking

Exam weight: 15–20%

Networking is the trickiest domain in AZ-104. The concepts are interconnected — getting one wrong (e.g., NSG vs UDR) cascades into wrong answers on multiple questions. Master the flow of traffic through Azure's network stack.

4.1 Virtual Networks (VNets)

A VNet is Azure's isolated network environment — the foundation of all Azure networking.

Key Rules

• VNet address space uses CIDR notation (e.g., 10.0.0.0/16).
• A VNet lives in one region and one subscription.
• Subnets partition the VNet. Each subnet must fall within the VNet's address space.
• Azure reserves 5 IPs in every subnet: .0 (network), .1 (default gateway), .2 and .3 (Azure DNS), .255 (broadcast).
• For a /28 subnet (16 addresses), you only get 11 usable host IPs.

Subnet Planning

4.2 Network Security Groups (NSGs)

An NSG is a stateful packet filter — the primary traffic control mechanism in Azure.

How Rules Work

Default (always-present) Rules

Inbound defaults:

Outbound defaults:

Exam trap: NSGs are stateful — if you allow inbound traffic on port 80, the return traffic is automatically allowed without a matching outbound rule.

NSG Attachment Points

An NSG can be associated with:

1. A subnet — applies to all resources in the subnet
2. A NIC — applies only to that specific VM's network interface

When associated to both, both NSGs are evaluated. For inbound: subnet NSG first, then NIC NSG. For outbound: NIC NSG first, then subnet NSG.

Exam trap: If a VM can't reach a destination, check both the subnet NSG and the NIC NSG. Both must allow the traffic.

Application Security Groups (ASGs)

ASGs are logical groupings of VMs that can be used as source/destination in NSG rules. Instead of IP-based rules, use ASG-based rules:

NSG Rule: Allow AppServers → DBServers on port 1433

This lets you add new app servers to the AppServers ASG without touching the NSG rules.

4.3 VNet Peering

VNet Peering connects two VNets — traffic flows over Microsoft's backbone network (private, low latency, not internet).

Key Characteristics

• Non-transitive by default. If VNet A is peered with B, and B is peered with C, then A cannot reach C directly. You need an explicit A↔C peering, or a transit hub with forwarding enabled.
• Peering is directional — you create two peering connections (A→B and B→A). The portal/CLI creates both automatically.
• Global peering: Peering across regions is supported.
• Address spaces cannot overlap.

Peering Settings

Exam trap: For a hub-spoke topology where spokes share the hub's VPN Gateway: enable allowGatewayTransit on the hub peering, and useRemoteGateways on the spoke peering. If these are reversed, transit doesn't work.

4.4 VPN Gateway

A VPN Gateway connects your Azure VNet to on-premises networks or other VNets over encrypted IPsec/IKE tunnels.

Connection Types

VPN Gateway SKUs

Exam trap: VPN Gateway requires a dedicated GatewaySubnet (named exactly GatewaySubnet, /27 minimum recommended).

Route-Based vs Policy-Based VPN

Exam tip: When in doubt, choose route-based. Policy-based is only needed for compatibility with very old VPN devices.

4.5 ExpressRoute

ExpressRoute provides a private, dedicated connection from on-premises to Azure — not over the internet.

Exam tip: "Consistent low latency" or "dedicated private connection" = ExpressRoute. "Fast to set up" or "cost-effective" = VPN Gateway.

ExpressRoute Peering Types

4.6 Azure DNS

Public DNS Zones

Host DNS records for internet-facing domains. Authoritative name servers are on Azure's global anycast network.

# Create a public DNS zone
az network dns zone create \
  --resource-group rg-net \
  --name contoso.com

# Add an A record
az network dns record-set a add-record \
  --resource-group rg-net \
  --zone-name contoso.com \
  --record-set-name "www" \
  --ipv4-address "203.0.113.1"

Private DNS Zones

Resolve private hostnames within VNets. VMs get automatic DNS records when auto-registration is enabled.

# Create a private DNS zone
az network private-dns zone create \
  --resource-group rg-net \
  --name "internal.contoso.com"

# Link it to a VNet (with auto-registration)
az network private-dns link vnet create \
  --resource-group rg-net \
  --zone-name "internal.contoso.com" \
  --name "link-to-prod-vnet" \
  --virtual-network "/subscriptions/.../virtualNetworks/prod-vnet" \
  --registration-enabled true

Exam trap: Azure DNS (public) does not support DNSSEC signing (as of AZ-104 curriculum). Private DNS zones must be linked to a VNet to be resolvable from within that VNet.

4.7 Load Balancer

Azure Load Balancer operates at Layer 4 (TCP/UDP) — it doesn't inspect HTTP content.

SKU Comparison

Exam trap: Standard Load Balancer + NSG. With Standard LB, you must have an NSG on the backend subnet or NIC explicitly allowing the traffic. Without it, backend VMs are unreachable even if the LB is configured correctly. Basic LB doesn't require this.

Load Balancer Rules

• Load balancing rules: Distribute traffic across backend pool
• NAT rules: Map a specific port on the LB to a specific VM port (e.g., LB:50001 → VM1:22)
• Health probes: LB periodically checks backend VM health; removes unhealthy instances

4.8 Application Gateway

Application Gateway is a Layer 7 (HTTP/HTTPS) load balancer with WAF capabilities.

URL-Based Routing Example

/images/* → Backend Pool: image-servers
/api/*    → Backend Pool: api-servers
/*        → Backend Pool: web-servers

Exam tip: If a question involves routing different URL paths to different backends, WAF, or SSL termination → Application Gateway. If it's just TCP load balancing → Azure Load Balancer.

4.9 Route Tables (User-Defined Routes)

Route tables override Azure's default routing and direct traffic to a specific next hop.

Next Hop Types

Common Pattern: Force Traffic Through Azure Firewall

Route: 0.0.0.0/0 → Next hop: VirtualAppliance → 10.0.1.4 (Firewall IP)

This forces all outbound traffic through the firewall for inspection.

Exam trap: UDR overrides BGP routes from VPN/ExpressRoute. If you have a route learned via BGP for 10.1.0.0/24 but also a UDR for 10.1.0.0/24, the UDR wins (more specific or explicitly defined routes take precedence).

NSG vs UDR — When to Use Which

They solve different problems. NSG is a filter; UDR is a redirect. They can be used together.

4.10 Private Endpoints vs Service Endpoints

Both provide private connectivity to Azure PaaS services — but they work differently.

Exam trap: Service endpoints don't give the PaaS service a private IP — traffic still goes to the public endpoint, just optimized routing. Only Private Endpoints give the service a private IP in your VNet and make it fully accessible over VPN/ExpressRoute.

Section Takeaways

Confusing Points — Clarified

Q: Can I have both an NSG and a UDR on the same subnet? A: Yes. NSG filters traffic (allow/deny). UDR redirects traffic to a next hop. They operate independently and together — UDR first redirects, then NSG evaluates.

Q: What's the difference between a Load Balancer health probe and an NSG? A: An NSG is a security filter. A health probe is how the Load Balancer determines if a backend VM is healthy enough to receive traffic. A VM can be "healthy" per the probe but still have an NSG blocking traffic — these are independent.

Q: If VNet A peers with VNet B and VNet B peers with VNet C, can VNet A communicate with VNet C? A: Not by default — peering is non-transitive. Either create a direct A↔C peering or configure VNet B as a transit hub with Azure Firewall or NVA and enable forwarded traffic.

Q: Does VNet peering work across Azure regions? A: Yes — this is called global VNet peering. The SLA and characteristics are the same as regional peering.