Azure AZ-104 Virtual Networks and Load Balancers

Why networking matters for the AZ-104 exam

Networking is an important part of the Microsoft Azure Administrator certification exam, AZ-104. An Azure administrator must understand how to create virtual networks, divide them into subnets, control traffic and make applications highly available.

Two central services in this area are Azure Virtual Network and Azure Load Balancer. A virtual network provides private network connectivity for Azure resources. A load balancer distributes incoming connections across healthy backend resources such as virtual machines.

The exam tests both concepts and administration tasks. You should be able to interpret a network design, select the correct service and configure resources through the Azure portal, Azure CLI or templates.

What is an Azure Virtual Network?

Azure Virtual Network, commonly called VNet, is the foundation for private networking in Azure. It allows resources such as virtual machines, private endpoints and internal load balancers to communicate using private IP addresses.

A VNet is logically isolated. Resources in one VNet cannot automatically communicate with resources in another VNet unless connectivity is configured.

A VNet design includes:

• An Azure region
• One or more private IP address spaces
• Subnets
• DNS settings
• Routing controls
• Security controls
• Connectivity to other networks

A VNet is scoped to one Azure region and one subscription, although it can communicate with VNets in other regions or subscriptions through VNet peering.

IP address spaces and subnets

When creating a VNet, you assign one or more IPv4 or IPv6 CIDR address ranges. Private IPv4 ranges defined by RFC 1918 are normally used:

Address planning is important. VNet address ranges must not overlap when you intend to connect networks through peering, a VPN or Azure ExpressRoute.

Understanding Azure subnets

A subnet divides a VNet address space into smaller networks. For example, the VNet 10.10.0.0/16 can contain these subnets:

• Web subnet: 10.10.1.0/24
• Application subnet: 10.10.2.0/24
• Database subnet: 10.10.3.0/24
• Management subnet: 10.10.4.0/24

Azure reserves five IP addresses in every subnet. These are the first four addresses and the last address. In 10.10.1.0/24, Azure reserves 10.10.1.0 through 10.10.1.3 and 10.10.1.255.

Subnets are commonly used to apply separate security and routing policies to application tiers. Some Azure services also require dedicated subnets with specific names or delegation settings. Examples include AzureBastionSubnet, GatewaySubnet and delegated subnets used by selected platform services.

Private and public IP addresses

Azure resources can use private and public IP addresses.

A private IP address supports communication inside a VNet, between peered VNets and across hybrid connections. Azure assigns private addresses dynamically by default, but administrators can select a static private address from the subnet range.

A public IP address allows communication with the internet. Standard SKU public IPv4 addresses use static allocation. Public IP addresses can be attached to resources such as public load balancers, NAT gateways, VPN gateways and selected virtual machine network interfaces.

For production designs, avoid assigning public IP addresses directly to every virtual machine. Use controlled entry points such as Azure Bastion, Azure Load Balancer, Application Gateway, Azure Firewall or a third-party network virtual appliance.

Network Security Groups

A Network Security Group, or NSG, filters inbound and outbound traffic. It contains ordered security rules that allow or deny traffic based on:

• Source and destination
• Source and destination ports
• Protocol
• Direction
• Priority

An NSG can be associated with a subnet, a network interface or both. If both associations exist, traffic must be allowed by the applicable rules at both levels.

Rules are processed in priority order, starting with the lowest number. Processing stops when Azure finds a matching rule. Priorities range from 100 to 4096 and must be unique within each direction.

NSGs are stateful. If an inbound flow is allowed, the return traffic is automatically permitted. You do not need a separate outbound rule for the response.

Azure creates default NSG rules, including rules for VNet traffic and Azure Load Balancer probes. Custom rules with higher priority can override default behaviour. When troubleshooting a load balancer, confirm that the backend NSG permits application traffic and health probes. The AzureLoadBalancer service tag can be used for probe traffic.

Routing in an Azure VNet

Azure automatically creates system routes for every subnet. These routes provide connectivity within the VNet and define default handling for internet-bound and other traffic.

A route table can contain user-defined routes, or UDRs, to override selected system routes. Common uses include:

• Sending internet traffic through Azure Firewall
• Directing traffic to a network virtual appliance
• Controlling communication between application tiers
• Routing traffic towards a VPN gateway

A route contains an address prefix and a next-hop type. Available next hops include virtual appliance, virtual network gateway, internet and none. The None next hop drops matching traffic.

Azure uses longest-prefix matching when choosing a route. If multiple routes have the same prefix, user-defined routes are generally preferred over Border Gateway Protocol routes, which are preferred over system routes.

Use Network Watcher tools such as effective routes, IP flow verify and connection troubleshoot when the configured design does not produce the expected traffic flow.

VNet peering and hybrid connectivity

VNet peering connects two Azure virtual networks through the Microsoft backbone. Traffic remains on the Azure network and does not require a public IP address, VPN appliance or gateway.

Peering has several exam-relevant characteristics:

• Peered VNets must have non-overlapping address spaces.
• Peering can connect VNets in the same or different regions.
• Peering is not transitive.
• Each direction requires a peering relationship.
• NSGs and route tables still apply.
• Gateway transit can allow one VNet to use another VNet's VPN or ExpressRoute gateway.

Non-transitive means that if VNet A is peered with VNet B and VNet B is peered with VNet C, VNet A does not automatically reach VNet C. A direct peering, routing appliance or another supported connectivity design is required.

For on-premises connectivity, Azure supports site-to-site VPN, point-to-site VPN and ExpressRoute. VPN connections use encrypted tunnels over the internet, while ExpressRoute provides private connectivity through a connectivity provider.

Service endpoints and private endpoints

Service endpoints extend a subnet's identity to supported Azure platform services. The service still uses its public endpoint, but access can be restricted to selected VNets and subnets.

A private endpoint creates a network interface with a private IP address inside the VNet. It provides private access to a specific service instance through Azure Private Link.

Private endpoints usually require DNS planning. Clients must resolve the service name to the private endpoint address, commonly through Azure Private DNS zones linked to the VNet.

For AZ-104 scenarios, remember this distinction: service endpoints secure access from a subnet to a service's public endpoint, while private endpoints bring a private service endpoint into the VNet.

What is Azure Load Balancer?

Azure Load Balancer is a Layer 4 load-balancing service. It distributes TCP and UDP flows across healthy backend instances. It does not inspect HTTP paths, host headers or cookies and does not terminate TLS connections.

Use Azure Application Gateway when Layer 7 features such as URL-based routing, TLS termination or Web Application Firewall are required.

Azure Load Balancer can support virtual machines and Virtual Machine Scale Sets. Its main purpose is to improve application availability and distribute connection load.

Public and internal load balancers

A public load balancer has a public frontend IP address. It accepts internet traffic and distributes it to backend resources.

An internal load balancer has a private frontend IP address from a subnet. It is used for private application tiers, internal services and hybrid workloads reachable through peering, VPN or ExpressRoute.

Standard Load Balancer is the current production SKU. Basic Load Balancer was retired, so new deployments and AZ-104 preparation should focus on Standard Load Balancer.

Standard Load Balancer is secure by default. An NSG must explicitly allow required inbound traffic to backend virtual machines.

Azure Load Balancer components

Understanding the relationship between components is essential for configuration and troubleshooting.

Frontend IP configuration

The frontend is the address clients use to connect. It can be a public IP address or a private address from a subnet. A load balancer can have multiple frontend IP configurations.

Backend pool

The backend pool contains the resources that receive traffic. Backend membership can be configured through network interfaces or IP addresses, depending on the design and resource type.

Backend instances must run the application on the port referenced by the load-balancing rule. Adding a VM to a backend pool does not install or start the application.

Health probe

A health probe checks whether a backend instance can receive traffic. Standard Load Balancer supports TCP, HTTP and HTTPS probes.

• A TCP probe checks whether a connection can be established on a port.
• An HTTP or HTTPS probe sends a request to a configured path.
• Unhealthy instances stop receiving new flows.

The application, operating system firewall and NSG must allow the probe. A working frontend rule cannot compensate for an incorrect health probe.

Load-balancing rule

A load-balancing rule connects a frontend IP and port to a backend pool and port. It also references a health probe and defines the protocol and session persistence settings.

For example, a rule can map frontend TCP port 80 to backend TCP port 80. Port translation is also possible, such as frontend port 443 mapped to a different backend port.

Session persistence can distribute traffic using a five-tuple hash, source IP or source IP and protocol. Azure Load Balancer does not provide application-cookie persistence.

Inbound NAT rule

An inbound NAT rule maps a frontend IP and unique port to a specific backend instance and port. It is often used for administrative access, although Azure Bastion is generally safer than exposing SSH or RDP to the internet.

A load-balancing rule distributes traffic across the pool. An inbound NAT rule targets one backend instance. This distinction is frequently tested.

Outbound connectivity

Do not assume that placing virtual machines behind a Standard Load Balancer automatically provides the preferred outbound internet design. Explicit outbound connectivity can be configured using Azure NAT Gateway, outbound rules or instance-level public IP addresses.

Azure NAT Gateway is generally the recommended option for scalable, predictable outbound connectivity from a subnet. It provides source network address translation and can use one or more static public IP addresses or public IP prefixes.

Creating a VNet and load balancer with Azure CLI

The following example creates a resource group, VNet and two subnets:

az group create \
  --name rg-az104-lab \
  --location centralindia

az network vnet create \
  --resource-group rg-az104-lab \
  --name vnet-app \
  --address-prefixes 10.20.0.0/16 \
  --subnet-name snet-web \
  --subnet-prefixes 10.20.1.0/24

az network vnet subnet create \
  --resource-group rg-az104-lab \
  --vnet-name vnet-app \
  --name snet-app \
  --address-prefixes 10.20.2.0/24

Create a Standard public IP address and Standard Load Balancer:

az network public-ip create \
  --resource-group rg-az104-lab \
  --name pip-web \
  --sku Standard \
  --allocation-method Static

az network lb create \
  --resource-group rg-az104-lab \
  --name lb-web \
  --sku Standard \
  --public-ip-address pip-web \
  --frontend-ip-name fe-public \
  --backend-pool-name be-web

Create a TCP health probe and load-balancing rule:

az network lb probe create \
  --resource-group rg-az104-lab \
  --lb-name lb-web \
  --name probe-http \
  --protocol Tcp \
  --port 80

az network lb rule create \
  --resource-group rg-az104-lab \
  --lb-name lb-web \
  --name rule-http \
  --protocol Tcp \
  --frontend-ip-name fe-public \
  --frontend-port 80 \
  --backend-pool-name be-web \
  --backend-port 80 \
  --probe-name probe-http

You must still add backend resources, allow TCP port 80 through the relevant NSG and confirm that the web service is listening on every backend instance.

Common troubleshooting checks

When an application is not reachable through Azure Load Balancer, check each layer in order:

1. Confirm that the frontend IP and port are correct.
2. Verify that the load-balancing rule uses the intended backend pool.
3. Check backend pool membership.
4. Confirm that the health probe reports healthy instances.
5. Verify that the application listens on the backend port.
6. Review subnet and network-interface NSG rules.
7. Check effective routes and user-defined routes.
8. Inspect the operating system firewall.
9. Validate DNS if clients connect by name.

This layered approach is useful in AZ-104 labs and real Azure support work.

AZ-104 preparation guidance

Do not prepare by memorising portal screens alone. Build a small environment and test what changes when you modify an NSG, route, health probe or backend pool.

Useful lab tasks include:

• Create a VNet with multiple subnets.
• Associate an NSG with a subnet.
• Configure and test VNet peering.
• Compare service endpoints and private endpoints.
• Deploy public and internal load balancers.
• Make a backend unhealthy and observe probe behaviour.
• Review effective security rules and effective routes.
• Configure outbound access with Azure NAT Gateway.

These skills are relevant to Azure administrator and cloud support roles in Chennai, Bangalore and other Indian technology hubs. Employers commonly expect practical troubleshooting ability in addition to certification knowledge.

Final summary

Azure Virtual Network provides private addressing, segmentation, routing, security and connectivity for Azure resources. Its core concepts include address spaces, subnets, NSGs, user-defined routes, peering and private access to platform services.

Azure Load Balancer provides Layer 4 distribution for TCP and UDP traffic. To configure it correctly, understand frontend IP configurations, backend pools, health probes, load-balancing rules, inbound NAT rules and outbound connectivity.

For AZ-104, focus on choosing the correct networking service and understanding the full traffic path. A correct configuration must align addressing, DNS, routing, security, application ports and health monitoring.