Networking is where a lot of AZ-900 candidates lose easy points. The concepts feel abstract, the acronyms blur together, and the exam is very good at putting two services that sound similar into the same question and asking which one fits. The reassuring news is that the AZ-900 stays firmly at the what is it and when do you use it altitude — you are never asked to configure a route table or write a firewall rule. You are asked to recognize the right building block for a described need.
This guide covers the networking portion of the Describe Azure compute and networking services objective, which sits inside the exam’s largest scored domain, Azure architecture and services (35–40%). Per the current skills measured, the networking bullet asks you to “describe virtual networking, including the purpose of Azure virtual networks, subnets, peering, Azure DNS, Azure VPN Gateway, and ExpressRoute” and to “define public and private endpoints.” That is the exact scope of this article — nothing more, nothing less — because knowing what is out of scope is half the battle. The compute half of that objective (VMs, App Service, containers, AKS) is covered separately in the Azure Compute Services guide; everything here assumes you already understand regions, availability zones, and the resource hierarchy that these networks are deployed into.
The Mental Model: A Private Network You Own in Azure
Every networking topic on the AZ-900 hangs off one idea: the Azure Virtual Network (VNet) is your own private, isolated slice of the Azure network. Once you can picture the VNet as a fenced-off property, the rest of the objective is just answering two questions — how do things inside the fence talk to each other? and how do things outside the fence get in (or reach out)?
| Question | Building blocks that answer it |
|---|---|
| How is my private network carved up internally? | Virtual network, subnets |
| How do two of my private networks connect? | VNet peering |
| How do names resolve to addresses? | Azure DNS |
| How does my on-premises datacenter connect to Azure? | VPN Gateway (over the internet) or ExpressRoute (private) |
| How do I reach an Azure PaaS service privately, or expose one publicly? | Private endpoints and public endpoints |
Keep that table in your head and most networking questions resolve to “which row is this describing?”
Azure Virtual Networks (VNets)
An Azure Virtual Network is the fundamental building block for private networking in Azure. It is a logically isolated network, defined by one or more private IP address ranges (CIDR blocks, typically from the RFC 1918 private space such as 10.0.0.0/16), into which you deploy resources like virtual machines. Resources inside the same VNet can communicate with each other privately by default, and the VNet controls how they communicate with the internet, with on-premises networks, and with each other.
Three facts the exam expects you to know:
- A VNet is scoped to a single region and a single subscription. It does not span regions — if you need private connectivity between two regions, you connect two VNets (see peering below). A VNet also lives inside one subscription, tying it to the logical hierarchy you studied earlier.
- VNets provide isolation and segmentation. Traffic stays private to the VNet unless you explicitly allow it out. This is the foundation of the defense-in-depth network layer — a topic covered from the security angle in the Identity, Access & Security guide.
- The purpose is private communication, not public exposure. A VNet is about resources talking to each other and to your on-premises world without traversing the public internet.
Subnets: Segmenting the VNet
A subnet is a subdivision of a virtual network’s address space. If the VNet is the property, subnets are the rooms — you take the VNet’s IP range and slice it into smaller ranges, then place resources into the appropriate subnet. Subnetting lets you organize and segment workloads: you might put web servers in one subnet, database servers in another, and apply different rules to each.
For the AZ-900 you only need the purpose, but two practitioner details make the concept concrete: Azure reserves five IP addresses in every subnet (the first four and the last), so a /24 subnet gives you 251 usable addresses rather than 256. And some Azure services require their own dedicated subnet — a VPN or ExpressRoute gateway must live in a specially named GatewaySubnet, for example. You will not be asked to size a subnet on the exam, but recognizing that subnets exist to segment a VNet is fair game.
VNet Peering: Connecting Two Virtual Networks
Virtual network peering connects two VNets so that resources in either one can communicate with each other as if they were on the same network. The traffic travels across the Microsoft backbone network — it is private, low-latency, and never touches the public internet. No gateway, VPN appliance, or public IP is required for basic peering.
The exam distinguishes two flavors:
| Peering type | Connects | Use case |
|---|---|---|
| Regional VNet peering | Two VNets in the same region | Segment workloads across VNets in one region |
| Global VNet peering | Two VNets in different regions | Connect workloads across regions privately |
Two properties worth remembering: peering is not transitive by default — if VNet A is peered with B, and B is peered with C, A and C cannot talk unless you peer them directly (or route through a hub). And peering is the answer whenever a scenario says “connect two Azure virtual networks privately” — if the scenario instead says “connect Azure to my on-premises datacenter,” you have moved into VPN Gateway or ExpressRoute territory.
Azure DNS: Name Resolution
Azure DNS is a hosting service for DNS domains, providing name resolution using Microsoft’s infrastructure. Its purpose is to translate friendly names (like app.contoso.com) into IP addresses. For the AZ-900, know the two contexts it operates in:
- Public DNS zones host the DNS records for a public domain you own, so internet clients can resolve your public-facing names to Azure.
- Private DNS zones provide name resolution within and between your virtual networks, without you having to deploy and manage your own DNS servers. This is how resources inside a VNet resolve each other (and private endpoints) by name.
You do not need to know record types or configuration steps. The takeaway is simply: Azure DNS is the managed service for hosting DNS and resolving names, with public zones for internet-facing domains and private zones for VNet-internal resolution.
Hybrid Connectivity: VPN Gateway vs ExpressRoute
This is the single most exam-tested distinction in the whole networking objective. Both services connect your on-premises network to Azure, but they do it in fundamentally different ways, and questions almost always turn on that difference.
Azure VPN Gateway creates an encrypted connection between your on-premises network and an Azure VNet over the public internet, using an IPsec/IKE VPN tunnel. It supports:
- Site-to-site — connecting a whole on-premises network to Azure.
- Point-to-site — connecting an individual client device (like a laptop) to Azure.
- VNet-to-VNet — connecting Azure VNets to each other via gateways.
The traffic is encrypted, but it still travels across the shared public internet, so latency and throughput depend on internet conditions.
Azure ExpressRoute establishes a private, dedicated connection between your on-premises network and Azure through a connectivity provider. Crucially, ExpressRoute traffic does not travel over the public internet at all. That gives you more reliable, consistent latency, higher and more predictable bandwidth, and better security posture for compliance-sensitive workloads — at a higher cost and with longer lead time to provision.
| Attribute | VPN Gateway | ExpressRoute |
|---|---|---|
| Path | Encrypted tunnel over the public internet | Private dedicated connection (bypasses the internet) |
| Performance | Depends on internet conditions | Consistent, low-latency, high-bandwidth |
| Cost | Lower | Higher |
| Setup time | Fast (software gateway) | Longer (provider circuit) |
| Typical trigger words | ”encrypted,” “over the internet,” “cost-effective,” “quick" | "private,” “not over the internet,” “consistent/predictable,” “high bandwidth,” “compliance” |
Exam reflex: if the scenario stresses cost, speed to set up, or “encrypted connection over the internet,” the answer is VPN Gateway. If it stresses “private connection that does not use the public internet,” predictable performance, or high, consistent bandwidth, the answer is ExpressRoute.
Public and Private Endpoints
The final networking bullet asks you to define public and private endpoints. This is about how you reach Azure PaaS services (like a storage account or an Azure SQL database), which by default are accessible over the internet.
- A public endpoint is a resource’s public-facing address, reachable over the internet via a public IP. Many PaaS services expose a public endpoint by default (for example, a storage account’s
https://<name>.blob.core.windows.netaddress). Convenient, but the service is reachable from the public internet unless you restrict it. - A private endpoint is a network interface, with a private IP address from your VNet, that connects privately and securely to a PaaS service using Azure Private Link. With a private endpoint, traffic to the service travels over the Microsoft backbone and your private network rather than the public internet, and the service effectively becomes part of your VNet’s address space.
| Public endpoint | Private endpoint | |
|---|---|---|
| Address | Public IP, internet-reachable | Private IP inside your VNet |
| Path | Over the public internet | Over the Microsoft backbone / your VNet (via Private Link) |
| Best when | Simplicity; the service is meant to be public | You want the PaaS service reachable only from your private network |
Exam reflex: “access a PaaS service privately, keep the traffic off the public internet, give it an IP inside my VNet” → private endpoint. “reachable over the internet” → public endpoint.
What Is Not on the AZ-900 (So You Don’t Over-Study)
A common trap is studying at AZ-104 depth and second-guessing yourself. The following are real and important Azure networking services, but they are not part of the current AZ-900 skills outline, and you should not expect them as scored exam objectives: Network Security Groups (NSGs), Azure Firewall, Azure Load Balancer, Application Gateway, Azure Front Door, and Azure Bastion. They belong to the administrator-level AZ-104 journey. Know that they exist and roughly what a firewall or load balancer does in general terms, but do not burn study time on their configuration for the AZ-900.
Scenario Cue Cheat Sheet
| The question describes… | The answer is… |
|---|---|
| ”A private, isolated network in Azure for my VMs” | Virtual network (VNet) |
| “Segment a VNet into smaller ranges for web and data tiers” | Subnets |
| ”Connect two Azure VNets so they communicate privately” | VNet peering |
| ”Connect VNets in two different regions privately” | Global VNet peering |
| ”Host DNS records / resolve names within a VNet” | Azure DNS (private zone for VNet-internal) |
| “Encrypted connection from on-prem to Azure over the internet” | VPN Gateway |
| ”Private, dedicated link to Azure that avoids the public internet” | ExpressRoute |
| ”Reach a storage account with a private IP inside my VNet” | Private endpoint (Azure Private Link) |
| “A PaaS service reachable over the internet by default” | Public endpoint |
Common Mistakes to Avoid
| Mistake | Reality |
|---|---|
| Thinking a VNet can span multiple regions | A VNet is regional; connect cross-region VNets with global peering. |
| Choosing VNet peering to reach an on-premises datacenter | Peering connects Azure VNets to each other; use VPN Gateway or ExpressRoute for on-prem. |
| Assuming ExpressRoute is “a faster VPN” | ExpressRoute is a private connection that bypasses the internet entirely — VPN Gateway rides the public internet. |
| Believing VNet peering is transitive | Peering is non-transitive by default; A↔B and B↔C does not give A↔C. |
| Confusing a private endpoint with a private DNS zone | A private endpoint gives a PaaS service a private IP in your VNet; private DNS resolves names to it. |
| Studying NSGs, Azure Firewall, or Load Balancer for AZ-900 | Those are AZ-104 topics, not scored AZ-900 objectives. |
Frequently Asked Questions
What is the difference between VNet peering and a VPN Gateway? VNet peering connects two Azure virtual networks to each other over the Microsoft backbone — it is for Azure-to-Azure private communication and needs no gateway. A VPN Gateway connects your on-premises network (or a remote client) to an Azure VNet, typically over the public internet via an encrypted tunnel. Different endpoints, different purpose.
When should I use ExpressRoute instead of a VPN Gateway? Choose ExpressRoute when you need a private connection that does not traverse the public internet, with consistent low latency and high, predictable bandwidth — common for large hybrid workloads, heavy data transfer, or compliance requirements. Choose a VPN Gateway when cost and quick setup matter more and an encrypted connection over the internet is acceptable.
What is the purpose of a subnet? A subnet segments a virtual network’s IP address range into smaller ranges so you can organize and isolate resources — for example, separating a web tier from a database tier. Resources are deployed into subnets, and some Azure services require a dedicated subnet.
What is the difference between a public and a private endpoint? A public endpoint exposes a service over the internet using a public IP. A private endpoint gives a PaaS service a private IP address inside your VNet (via Azure Private Link), so you can reach it privately without the traffic going over the public internet.
Does Azure DNS cost extra, and do I need it? Azure DNS is a managed hosting service for DNS; for the AZ-900 you only need to know its purpose — hosting DNS domains and resolving names — not pricing. Public zones handle internet-facing domain records; private zones handle name resolution inside your virtual networks.
Is a virtual network the same as a subscription or resource group? No. A subscription and a resource group are logical/billing containers in Azure’s management hierarchy. A virtual network is a networking resource that lives inside a subscription and is scoped to a single region. Review the core architecture guide if that distinction is fuzzy.
Do I need to learn Network Security Groups for the AZ-900? No. NSGs, Azure Firewall, Azure Load Balancer, Application Gateway, Front Door, and Azure Bastion are not in the current AZ-900 skills outline — they are AZ-104-level topics. Focus your AZ-900 networking study on VNets, subnets, peering, Azure DNS, VPN Gateway, ExpressRoute, and public/private endpoints.
Practice Until the Cues Are Automatic
Azure networking on the AZ-900 rewards pattern recognition: hear “two Azure VNets, private” and think peering; hear “on-prem, encrypted, over the internet” and think VPN Gateway; hear “private, not over the internet, consistent bandwidth” and think ExpressRoute; hear “private IP for a PaaS service inside my VNet” and think private endpoint. Those reflexes come from answering scenario questions until the trigger words map themselves.
Sailor.sh’s AZ-900 Fundamentals mock exam bundle — 8 full-length mock exams aligned to the current skills measured blueprint — weights the Azure architecture and services domain heavily, so you drill exactly these networking discriminations under timed, exam-realistic conditions. To try the format first, work through the free AZ-900 practice questions and the full AZ-900 practice set.
To finish the rest of Azure architecture and services, pair this with the Azure Compute Services guide and the core architectural components guide, then connect the security angle in Identity, Access & Security and the operations angle in Management & Governance. New to the exam? Start with the AZ-900 exam guide for 2026, schedule your prep with the 30-day AZ-900 study plan, and if you are still deciding, read is the AZ-900 worth it in 2026 or compare paths in AZ-900 vs AWS Cloud Practitioner.