AZ-104 Skill 4: Implement and Manage Virtual Networking

Deep-dive guide | VNets, Network Security, Private Connectivity, DNS, and Load Balancing for the Azure Administrator

Networking is the connective tissue of every Azure workload. Without it, virtual machines cannot communicate, applications cannot be reached by users, and services remain isolated islands. Microsoft allocates 15–20% of the AZ‑104 exam to networking because, as an administrator, you configure the pathways that make everything else work—and misconfigurations here are among the most common causes of cloud outages.

This guide maps every tested networking skill to the underlying Azure domains, the architectural decisions that shape secure, scalable networks, and the real‑world enterprise patterns you will build.

1. Overview

#

Every Azure resource that has a network interface—VMs, App Service with VNet integration, Azure Kubernetes Service, private endpoints—depends on a properly designed virtual network. Networking determines:

• How resources communicate within Azure and with on‑premises environments.
• Who can access what (security boundaries via NSGs and ASGs).
• How users reach applications (load balancing, DNS resolution).
• How Azure PaaS services are consumed privately (service endpoints, private endpoints).

As an administrator, you create and manage VNets, subnets, peering, routing, and security rules. As you progress toward architecture, the same skills underpin landing zone design, hybrid connectivity, and zero‑trust networking. AZ‑104 tests the operational layer, but understanding the architecture behind it makes you both exam‑ready and production‑ready.

2. Skill Area Breakdown

#

Microsoft’s official skills for this area cover three core capabilities.

Virtual Networks and Connectivity

#

• VNet and subnet creation: Define address spaces (CIDR blocks) and carve them into subnets that group resources by function (web, app, data, management).
• VNet peering: Connect VNets directly using the Microsoft backbone; requires non‑overlapping address spaces.
• Public IP addresses: Assign static or dynamic public IPs to resources (load balancers, NAT gateways, VM NICs).
• User‑defined routes (UDRs): Override Azure’s default system routes to force traffic through a firewall or NVA.
• Troubleshoot connectivity: Diagnose issues with Network Watcher tools (IP flow verify, next hop, connection troubleshoot).

Secure Access to Virtual Networks

#

• Network security groups (NSGs): Stateful allow/deny rules based on source/destination IP, port, and protocol, applied to subnets or NICs.
• Application security groups (ASGs): Logical labels that group NICs, simplifying NSG rules to use application tiers as source/destination instead of IPs.
• Evaluate effective security rules: Determine the net effect of all NSG rules and priority on a NIC or subnet.
• Azure Bastion: PaaS service that provides secure, browser‑based RDP/SSH access to VMs without exposing public IPs.
• Service endpoints: Extend your VNet’s identity to Azure PaaS services (Azure Storage, Azure SQL) to restrict service access to only specific subnets.
• Private endpoints: Assign a private IP from your VNet directly to a specific instance of a PaaS service, keeping all traffic on the Azure backbone and eliminating public exposure entirely.

Name Resolution and Load Balancing

#

• Azure DNS: Host public DNS zones for your domains or create private DNS zones for VNet‑internal name resolution, automatically registering VM names.
• Internal load balancer: Distribute traffic among backend VMs within a VNet; used for intra‑application tiers.
• Public load balancer: Map a public IP to backend VMs for internet‑facing applications.
• Troubleshoot load balancing: Verify health probes, backend pool health, and load balancing rules.

These capabilities form a layered networking stack: VNets provide isolation, peering connects them, NSGs/ASGs and endpoints secure traffic, DNS resolves names, and load balancers distribute traffic.

3. Azure Domains Mapping

#

Each networking exam skill draws from one or more foundational Azure domains.

Understanding these domain mappings helps you recall the correct constraints. For example, a question about securing access to Azure SQL from a VNet is a Private Connectivity question; a question about distributing HTTP traffic to multiple VMs is a Load Balancing question.

4. Azure Architecture Mapping

#

Architecture decisions transform isolated administrative tasks into a cohesive, secure, and scalable network design.

Networking Architecture

#

• VNet design: Choose address spaces large enough for future growth. A typical enterprise uses a hub‑spoke topology: a hub VNet contains shared services (firewall, gateway, management), and spoke VNets host workloads. Address spaces must not overlap.
• Subnet design: Segment by function and security boundary. Avoid a single large subnet; use separate subnets for web, application, data, and management (Azure Bastion).
• Address planning: Reserve sufficient IPs for each subnet, factoring in service endpoints, private endpoints, and future scaling.

Secure Networking Architecture

#

Defense in depth is implemented with layered network controls:

• Micro‑segmentation: Use NSGs on subnets and ASGs for application‑centric rules. For example, allow traffic only from the “WebServers” ASG to the “AppServers” ASG on specific ports.
• Secure management: Azure Bastion provides just‑in‑time, audited access to VMs without opening RDP/SSH to the internet.
• Outbound control: Use UDRs to force all outbound traffic through an Azure Firewall or NVA for inspection.

Hybrid Networking Architecture

#

While on‑premises integration is not the primary focus of AZ‑104, you must understand how VNet peering and gateways connect networks.

• VNet peering: Connects VNets across regions and subscriptions. It is non‑transitive by default; to enable transitive routing, you need a hub VNet with an NVA or Azure Route Server.
• VPN Gateway / ExpressRoute: Used for hybrid connectivity to on‑premises. The exam may test gateway transit settings in peering to allow spoke VNets to use the hub’s gateway.

Private Connectivity Architecture

#

Two approaches to access Azure PaaS services privately:

• Service Endpoint: Extends the VNet identity to the service, allowing you to restrict the service firewall to only specific subnets. Traffic still uses the service’s public endpoint, but the source IP is from the VNet.
• Private Endpoint: Places the service directly inside your VNet with a private IP. No public endpoint is exposed. This is the gold standard for security, required by many compliance standards.

A simple diagram illustrates the difference:

Load Balancing Architecture

#

• Azure Load Balancer (L4): Distributes TCP/UDP traffic based on 5‑tuple hash. Ideal for non‑HTTP workloads or basic web traffic. Available in public and internal SKUs.
• Application Gateway (L7): HTTP/HTTPS load balancing with SSL termination, cookie‑based affinity, and Web Application Firewall (WAF). Not directly tested in AZ‑104 but useful to know for architectural context.
• Traffic Manager / Front Door: Global DNS‑based and L7 load balancing (outside AZ‑104 scope).

Enterprise Landing Zone Networking

#

A well‑architected enterprise network might look like this:

Administrators configure the subnets, NSGs, peering, private endpoints, and load balancers that bring this architecture to life.

5. Azure Services Deep Dive

#

Virtual Network (VNet)

#

• Core model: A VNet is an isolated network boundary. It spans all availability zones in a region. You define one or more address spaces (CIDR ranges) and subdivide into subnets.
• Subnets: Each subnet must fall within the VNet’s address space. Azure reserves 5 IP addresses per subnet (x.x.x.0‑3 and last), so plan capacity accordingly.
• Network boundaries: Resources in different VNets cannot communicate by default. Peering enables connectivity.

VNet Peering

#

• Purpose: Connect two VNets with low‑latency, high‑bandwidth backbone connectivity. No gateway required; traffic is private and encrypted.
• Requirements: Address spaces must not overlap. Peering is not transitive (VNet A peered with B, B peered with C, A cannot reach C unless a router or gateway transit is configured).
• Gateway transit: Allows a spoke VNet to use the hub’s VPN/ExpressRoute gateway to reach on‑premises.

Network Security Groups (NSG)

#

• Rule processing: Rules are stateful; if an inbound request is allowed, the return traffic is automatically allowed. Rules are evaluated by priority (lower number = higher priority). The last rule is always “DenyAllInbound”/“DenyAllOutbound” with priority 65500.
• Association: An NSG can be associated to a subnet, a NIC, or both. Effective rules are the union of both, with subnet rules evaluating first.
• Effective security rules: Use the portal or Network Watcher to see the combined effect.

Application Security Groups (ASG)

#

• Purpose: Group NICs by application role (e.g., “WebServers”, “AppServers”). NSG rules can then reference ASGs instead of IP addresses, simplifying rule management.
• Example: Allow inbound TCP 443 from source ASG “WebServers” to destination ASG “AppServers”.

Azure Bastion

#

• Architecture: A managed jump host provisioned into a dedicated subnet called AzureBastionSubnet (minimum /26). Connects to VMs via private IP only, over TLS. No public IPs on VMs needed.
• Use case: Replace jumpbox VMs; provide secure, audited administrative access.

Service Endpoints

#

• Function: Enable a subnet to access specific Azure services (e.g., Storage, SQL) by adding the subnet’s identity to the service firewall. The service must have a firewall rule allowing that subnet.
• Limitations: Traffic still uses the service’s public endpoint; the source IP changes to the VNet’s private IP. Does not protect against data exfiltration if the service allows other authentication.

Private Endpoints

#

• Architecture: A private IP from your VNet is assigned to a specific resource’s network interface. All traffic to that resource flows over Azure Private Link, never touching the public internet.
• Advantages: Eliminates public exposure, enables access over ExpressRoute/VPN from on‑premises, and protects against data exfiltration.
• Requirements: Requires a Private DNS Zone to resolve the service’s FQDN to the private IP.

Azure DNS

#

• Public DNS: Host your public domain zones in Azure; manage A, CNAME, MX records. Can be used for domain registration.
• Private DNS: Create zones that are resolvable only within linked VNets. Supports auto‑registration of VM hostnames. Essential for private endpoint resolution.

Azure Load Balancer

#

• SKU: Basic (legacy, limited features) vs Standard (recommended, supports availability zones, HA ports, and is required for VMSS). The exam will likely refer to Standard.
• Internal vs Public: Internal LB has a private frontend IP; Public LB has a public frontend IP.
• Backend pools: Can be NICs, IP addresses, or VMSS.
• Health probes: TCP, HTTP, or HTTPS probes determine backend health. Misconfigured probes are a common cause of load balancer failures.

6. Networking Decision Framework

#

Cost considerations:

• VNet peering incurs ingress/egress charges (not free within region but lower than internet).
• Private endpoints have an hourly cost and data processing charges.
• Azure Bastion is priced per hour plus outbound data.
• Load Balancer Standard has hourly and per‑rule costs; Basic is free but limited.

7. Real‑World Enterprise Scenario

#

Company: Contoso needs a secure, isolated Azure environment.

Requirements:

• Production and development workloads must be isolated.
• An Azure SQL Database in production must only be accessible from the production application tier and never from the internet.
• Administrators must securely manage VMs without exposing RDP/SSH to the internet.
• A customer‑facing web application must be highly available and reachable via a single public IP.
• Workloads must be able to resolve each other by name.

Solution design:

• VNet structure: Hub‑spoke with Hub VNet (10.0.0.0/16), Prod Spoke (10.1.0.0/16), Dev Spoke (10.2.0.0/16). Peering connects spokes to hub. Address spaces are non‑overlapping.
• Subnets: Prod Spoke has web, app, and data subnets. Web subnet contains VMs in an Availability Set behind a public Standard Load Balancer. App subnet contains application VMs. Data subnet hosts the private endpoint for Azure SQL.
• Security: NSG on web subnet allows inbound HTTPS (443) from the internet. NSG on app subnet allows only traffic from the WebServers ASG (the web VMs). The Azure SQL database is configured with public access disabled and accessible only through its private endpoint in the data subnet.
• Administrator access: Azure Bastion deployed in Hub VNet’s AzureBastionSubnet. Administrators connect via Bastion to manage VMs in any peered VNet (with appropriate NSGs allowing Bastion traffic).
• Load balancing: Public Standard Load Balancer distributes user traffic to web VMs. Health probes monitor web server ports.
• Name resolution: Private DNS zones privatelink.database.windows.net are linked to Prod Spoke to resolve the SQL database private IP. Additional custom private DNS zones can be created for VM name resolution.

This design satisfies all requirements using the exact services tested in AZ‑104.

8. AZ‑104 Exam Thinking

#

VNet and Peering Questions

#

• “You need to connect VNet A (10.0.0.0/16) and VNet B (10.0.0.0/24).” Not possible—address spaces overlap. You must change one.
• “VNet A is peered to VNet B. VNet B has a VPN gateway to on‑premises. How can VNet A reach on‑premises?” Enable “Use remote gateway” on VNet A’s peering and “Allow gateway transit” on VNet B’s peering.
• Route troubleshooting: Use Network Watcher’s “Next hop” to see where packets go. UDRs can override system routes.

Security Questions (NSG/ASG/Bastion)

#

• Rule priority: Lower number wins. If a rule with priority 100 denies port 22 and priority 200 allows port 22, the deny takes effect.
• Effective rules: When an NSG is on both subnet and NIC, subnet rules are evaluated first for inbound, NIC rules first for outbound. Know that a subnet‑level NSG that blocks traffic cannot be overridden by a NIC‑level NSG allowing the same traffic.
• ASG vs explicit IP: The exam favors ASGs for maintainability. If a scenario says “you need to apply rules to a group of VMs that may change,” ASG is the answer.
• Bastion: If the requirement is “you must allow RDP access to a VM without exposing a public IP,” the answer is Azure Bastion.

Private Connectivity Questions

#

• Service endpoint vs private endpoint: If the requirement says “the service must not be accessible from the internet” → private endpoint. If it says “restrict access to the service to your VNet, but allow access via the service’s public endpoint if needed” → service endpoint.
• Private endpoint DNS: You must configure a private DNS zone or a custom DNS server for the private IP to be resolved. The exam often checks this prerequisite.

DNS and Load Balancing Questions

#

• Internal vs public load balancer: If backend VMs have no public IPs and need to receive internet traffic, public LB is needed. For internal traffic between tiers, internal LB.
• Health probe failures: A backend VM marked as “Unhealthy” could be due to the probe port not being open in NSG, the service not running, or the probe path incorrect.
• Azure DNS: Create a private zone linked to VNets to enable VM name resolution. Auto‑registration will add A records for VMs.

9. Practice Scenarios

#

Scenario 1 – VNet Peering

#

You have VNet1 (address space 10.1.0.0/16) and VNet2 (10.2.0.0/16). You peer them. Later, you expand VNet1’s address space to 10.0.0.0/14, which now overlaps VNet2.

What is the effect on the peering?

A. The peering continues to work, but VNet2’s address space is automatically changed to avoid overlap. B. The peering enters a “Disconnected” state and must be recreated after adjusting address spaces. C. Traffic will still flow because overlapping address spaces are handled by Azure. D. The peering is automatically deleted.

Correct answer: B
Explanation: Overlapping address spaces cause peering to fail. The status becomes “Disconnected” or the peering operation fails. You must re‑architect the address spaces.
Architecture reasoning: Address space planning must be forward‑looking to avoid collisions.
Related services: Virtual Network, VNet Peering.

Scenario 2 – NSG Rule Troubleshooting

#

A developer reports that an application on VM1 cannot reach VM2 on port 1433. You check the NSG on VM2’s subnet and see these rules:

• Priority 100: Allow source ASG “AppServers” to destination any port 1433
• Priority 200: Deny all inbound from any to any

VM1’s NIC is a member of ASG “WebServers”, not “AppServers”.

What is the most efficient way to allow the traffic while maintaining security?

A. Change the priority 100 rule’s source ASG to “WebServers”. B. Add VM1’s IP to the priority 100 rule’s source. C. Remove the priority 200 deny rule. D. Add a new rule with priority 50 allowing source IP of VM1 to port 1433.

Correct answer: A
Explanation: Since the requirement is to allow an application group, updating the source ASG to “WebServers” (if that represents the correct tier) is maintainable. If “WebServers” should also be allowed, adding it as an additional source ASG is best, but the options here point to changing the existing rule. Option A is clean.
Architecture reasoning: Use ASGs to logically group VMs by role, making rule changes consistent.
Related services: NSG, ASG.

Scenario 3 – Private Endpoint

#

You have a VNet with a subnet that contains application VMs. You need to connect to an Azure SQL Database so that no traffic leaves the Microsoft backbone and the database has no public endpoint.

What two actions should you perform?

A. Create a service endpoint for Azure SQL on the subnet. B. Create a private endpoint for the SQL Database in the VNet. C. Configure a Private DNS zone for privatelink.database.windows.net and link it to the VNet. D. Add a rule to the SQL Database firewall to allow the VNet’s public IP.

Correct answer: B and C
Explanation: Private endpoint ensures no public exposure. Private DNS is required for the application to resolve the database FQDN to the private IP.
Architecture reasoning: Private Link provides complete network isolation; DNS integration is mandatory for transparent resolution.
Related services: Private Link, Private Endpoint, Private DNS.

Scenario 4 – Load Balancer Health Probe

#

You deploy a public Standard Load Balancer with backend VMs running a web server on port 80. After setup, the backend VMs show as “Unhealthy.”

What is a likely cause?

A. The health probe is configured on port 443 but the VMs listen on port 80. B. The backend VMs are in a different VNet than the load balancer. C. The load balancer has no public IP. D. The VMs have a dynamic private IP.

Correct answer: A
Explanation: If the health probe port does not match the application port, the load balancer will mark the VMs as unhealthy because the probe fails.
Architecture reasoning: Always align health probe settings with the actual application health endpoint.
Related services: Azure Load Balancer, health probes.

Scenario 5 – Azure DNS

#

Your VNet VNet1 contains VMs that need to communicate with each other using hostnames (e.g., appserver01.contoso.internal). Azure‑provided DNS only resolves hostnames within the same VNet using the Azure‑supplied suffix; you need a custom domain suffix.

What should you create?

A. A public DNS zone named contoso.internal and add A records manually. B. A private DNS zone named contoso.internal, link it to VNet1, and enable auto‑registration. C. A public DNS zone and a CNAME record pointing to the VMs’ public IPs. D. An Azure DNS alias record.

Correct answer: B
Explanation: Private DNS zones allow custom domain suffixes and auto‑registration of VM hostnames, providing exactly the desired name resolution within the VNet.
Architecture reasoning: Private DNS zones are the standard solution for internal name resolution in Azure.
Related services: Azure Private DNS, Virtual Network.

10. Common Exam Mistakes

#

• Confusing NSGs and ASGs: NSG is the rule container; ASG is a grouping mechanism used within rules. ASGs don’t have rules themselves.
• Confusing Service Endpoints and Private Endpoints: Service endpoints extend VNet identity to the service but still use public endpoint; private endpoints bring the service into your VNet.
• Using public access when private connectivity is required: If the scenario says “no access from the internet,” always select Private Endpoint.
• Poor subnet planning: Not considering the 5 reserved IPs or overlapping CIDR blocks when peering.
• Misunderstanding VNet Peering limitations: Peering is not transitive by default; overlapping address spaces break peering; global peering (cross‑region) is available but not all features (like gateway transit) are supported globally without workarounds.
• Choosing the wrong load‑balancing service: Azure Load Balancer is L4 only; for HTTP‑level features you need Application Gateway. AZ‑104 focuses on L4 Load Balancer, so don’t confuse them.
• Overlooking health probe configuration in load balancer troubleshooting.
• Ignoring DNS configuration for private endpoints: Without a private DNS zone, the private IP won’t resolve, and the application may try the public endpoint (which could be disabled).

11. Skill 4 Learning Checklist

#

Must Know (exam‑critical)

#

• Create a VNet with multiple subnets, correctly sizing address spaces
• Configure VNet peering between two VNets (with gateway transit settings)
• Create and assign public IP addresses (static vs dynamic)
• Create and configure user‑defined routes (UDRs) to override default routes
• Use Network Watcher tools (IP flow verify, next hop, connection troubleshoot)
• Create and associate NSG rules with subnets and NICs; evaluate effective security rules
• Create and use Application Security Groups (ASGs) in NSG rules
• Deploy Azure Bastion in a dedicated subnet and use it for secure VM access
• Configure service endpoints for Azure Storage or Azure SQL
• Configure private endpoints and associated private DNS zones
• Configure Azure DNS public and private zones, including auto‑registration
• Deploy and configure an internal and a public Azure Load Balancer (Standard SKU)
• Configure health probes, load balancing rules, and backend pools

Should Know (strong working knowledge)

#

• Understand NSG rule processing order (subnet vs NIC)
• Know when to use UDRs to force traffic to Azure Firewall or NVA
• Configure VNet peering across subscriptions and Azure Active Directory tenants
• Understand the differences between Basic and Standard Load Balancer SKU
• Troubleshoot load balancer uneven distribution (5‑tuple hash affinity)
• Configure a private link service (exposing a service behind a private endpoint)

Nice to Know (architecture context)

#

• Hub‑spoke network design with shared services VNet
• Use of Azure Virtual WAN for large‑scale branch connectivity
• Integration of Azure Firewall with forced tunneling
• ExpressRoute design fundamentals (not required but useful for hybrid scenarios)
• Azure Front Door and Application Gateway for L7 global load balancing

12. What’s Next

#

Networking is what makes compute, storage, and applications reachable and secure. The final piece of the AZ‑104 puzzle is ensuring all these resources are healthy, performant, and recoverable. In AZ‑104 Skill 5: Monitor and Maintain Azure Resources, you’ll configure alerts, logs, metrics, backup, and disaster recovery—closing the loop from deployment to ongoing operations.

AZ‑104 Skill 5: Monitor and Maintain Azure Resources →

Related Architecture and Domain Content

#

• Networking domain deep‑dive: /azure/domains/networking
• Security domain overview: /azure/domains/security
• Observability domain (monitoring): /azure/domains/observability
• Networking architecture patterns: /azure/architecture/networking-architecture
• Secure networking architecture: /azure/architecture/secure-networking-architecture
• Private connectivity architecture: /azure/architecture/private-connectivity-architecture
• Load balancing architecture: /azure/architecture/load-balancing-architecture
• Hybrid cloud networking: /azure/architecture/hybrid-cloud-architecture
• Virtual Network service guide: /services/virtual-network
• Network Security Groups reference: /services/network-security-group
• Application Security Groups: /services/application-security-group
• Private Endpoint and Private Link: /services/private-endpoint
• Azure Bastion: /services/azure-bastion
• Azure DNS: /services/dns
• Azure Load Balancer: /services/load-balancer
• Application Gateway (context): /services/application-gateway