The AZ-104 networking domain accounts for 15–20% of the entire exam. The core topics are VNet configuration, security, DNS, and load balancing. The terminology may feel unfamiliar at first, but once you understand each concept through real-world analogies, it turns out to be much easier than you might think.
VNet and Subnets
What is a VNet?
A VNet (Virtual Network) lets you create your own private network inside Azure. Simply put, it is like constructing a dedicated office building just for your company inside the vast Azure cloud. Employees inside the building can communicate freely with each other, but outsiders cannot walk in as they please.
When you create a VNet you define an address space (CIDR). Specifying , for example, sets the range of internal addresses that building can use — much like deciding the room-numbering scheme for the whole building.
Subnets are the concept of dividing that building floor by floor. You can zone it by purpose: floor 1 for web servers, floor 2 for databases, floor 3 for management systems. Dividing it this way lets you apply different security rules per floor and isolate a specific zone when a problem occurs, making management far more convenient.
VNet Peering: A Dedicated Corridor Connecting Two Buildings
As a business grows, there may be a building in Seoul and another in Busan. How do they communicate? Going through the public internet is slow and exposes you to security risks. VNet Peering creates a dedicated corridor between two VNets via Azure's internal backbone network — no internet, so it is fast and secure.
There are two kinds of VNet Peering:
Local Peering: Connects two VNets within the same Azure region (e.g., Korea Central). Like connecting two offices in the same city with a dedicated line. Global Peering: Connects VNets in different regions (e.g., Korea Central and East US). Like connecting a Seoul headquarters and a New York branch with an international dedicated line.
Key characteristic: Non-transitivity
There is a rule about VNet Peering you must remember: it is non-transitive. Here is an example to explain what that means.
Suppose Building A and Building B are connected by a dedicated corridor, and Building B and Building C are also connected by a dedicated corridor. Can you travel from Building A through Building B to reach Building C? No. VNet Peering represents only a direct connection between two VNets. For A and C to communicate, you must configure a separate A↔C Peering. This rule is frequently tested on the exam.
UDR (User Defined Route): You Decide the Path of Traffic
By default, Azure automatically determines the optimal path for traffic to reach its destination. However, for security reasons you may need to force all traffic to pass through a specific checkpoint. For example, if you want all external traffic to go through an NVA (Network Virtual Appliance) acting as a firewall, you use a UDR.
A UDR (User Defined Route) overrides Azure's default routing rules and lets you specify exactly which path traffic must take. It is like mandating that vehicles on a highway must pass through a tollgate (NVA) at a certain stretch. This lets you inspect all traffic and block suspicious packets.
Network Security
NSG (Network Security Group): The Building's Security Guard
An NSG is like a security guard for your network. It defines rules for who can come in (inbound) and who can go out (outbound). These rules can be applied to an entire subnet or to the network interface (NIC) of an individual VM.
For example, on the subnet hosting web servers you could create a rule that says "only allow traffic on port 80 (HTTP) and port 443 (HTTPS) from outside; block everything else."
Understanding Priority Rules
NSG rules have priority numbers. The lower the number, the earlier it is evaluated. If a priority-100 rule and a priority-1000 rule conflict, the priority-100 rule is applied first.
It is like a security guard reading a work-instruction manual where item 1 is checked before item 10. By placing allow rules at high priority (low numbers) and deny rules at low priority (high numbers) — or vice versa — you can exercise fine-grained control over traffic.
Default Rules (Cannot Be Changed)
Azure automatically includes default rules in every NSG: Communication within the VNet is allowed Outbound traffic to the internet is allowed All other inbound traffic is blocked
These default rules cannot be deleted, but you can override them by adding rules with a lower number (higher priority).
ASG (Application Security Group): Manage by Role, Not by IP
What happens when you have 10 or 20 servers? Specifying each server's IP address one by one in NSG rules becomes very complex. When a server's IP changes, you have to update all the rules too.
ASG (Application Security Group) solves this problem. It groups VMs into logical groups by role, so NSG rules can reference a group name instead of IP addresses.
For example, group 10 web servers into an ASG called 'WebServers' and 5 database servers into an ASG called 'DatabaseServers'. Then define the NSG rule as "allow port 1433 from WebServers to DatabaseServers." Now, when a server is added or its IP changes, you just add that server to the ASG — no need to modify the NSG rules themselves. It is like managing access permissions by department name ('Sales Team', 'Dev Team') instead of by individual employee lists.
!NSG versus ASG
Azure Bastion: Securely Access VMs Without a Public IP
Normally, to connect to a server remotely it needs a public IP, and you have to open RDP (port 3389) or SSH (port 22) to the internet. Doing so gives hackers a persistent target to attack.
Azure Bastion completely solves this problem. Even without assigning a public IP to the VM, you can securely access the VM through a web browser in the Azure portal. There is no need to expose RDP or SSH ports to the internet.
By analogy: instead of publicly advertising your office room number at the building's front entrance, all visitors are escorted inside only through a tightly secured reception desk (Bastion). Outsiders never learn a specific room number — they must always go through reception.
Service Endpoint vs. Private Endpoint: Two Ways to Connect Privately
When accessing Azure services such as Azure Storage or SQL Database, resources inside a VNet can connect more securely and efficiently in two ways.
A Service Endpoint optimizes the path from a VNet to an Azure service. Traffic moves through Azure's internal network instead of the internet. However, the Azure service still has a public IP address. By analogy: instead of taking a regular road to the airport, you use a dedicated expressway. Faster and less congested, but the airport itself is still a public place.
A Private Endpoint goes one step further. It assigns a private IP address from within your VNet directly to the Azure service. The service now behaves as if it were a resource inside your VNet. It cannot be reached from the internet — only from within the VNet. By analogy: a specific VIP lounge at the airport has physically relocated into your company's office building. It is completely accessible only from inside.
In summary: Service Endpoint: Uses public IP address, but the path is optimized (fast and simple) Private Endpoint: Assigns a private IP, fully isolated (more secure, more complex)
!Service Endpoint versus Private Endpoint
DNS
Why Do We Need DNS?
DNS (Domain Name System) is like the internet's phone book. When we type an address like , it is actually converted to a numeric IP address like for communication. DNS handles this conversion.
Azure Public DNS: Manage Your Domain in Azure
Azure Public DNS lets you manage DNS records for a domain your company owns (e.g., ) in Azure. It supports various DNS record types: A records (domain → IP address), CNAME records (domain alias), MX records (mail server), TXT records (domain ownership verification), and more.
For example, to point to the public IP of a specific Azure VM, create an A record. To point to , create a CNAME record.
Azure Private DNS: An Internal Phone Book Used Only Inside the VNet
VMs inside a VNet communicate using internal IPs. But memorizing IP addresses is inconvenient, and managing them becomes difficult when VMs are added or IPs change. An Azure Private DNS Zone is an internal DNS system used exclusively within a VNet.
For example, create a Private DNS Zone and link it to a VNet. VMs in that VNet can then find each other using names like . This DNS name resolves to nothing on the public internet — it works only inside the VNet.
The auto-registration feature is especially handy. When a VM is created in the VNet, its name and IP are automatically registered in Private DNS. No need to create DNS records manually. It is like a new employee being automatically added to the company phone directory on their first day.
You can also link multiple VNets to a single Private DNS Zone, maintaining a consistent internal DNS naming scheme across multiple VNets.
Azure Load Balancer: A Traffic Director That Distributes Work Evenly
As a service grows, a single VM cannot handle all requests. You need multiple VMs ready and traffic distributed evenly among them. That is the role of a Load Balancer — like a traffic officer at a busy intersection directing vehicles into multiple lanes.
Two Types of Load Balancer
| Type | Description | Use Case | |------|-------------|----------| | Public Load Balancer | Distributes inbound internet traffic across multiple VMs | Distributing website visitor traffic | | Internal Load Balancer | Distributes internal VNet traffic across multiple VMs | Placed in front of internal API servers or databases |
A public Load Balancer accepts requests from external users and distributes them across multiple web servers. An internal Load Balancer is used only inside the VNet — for example, distributing requests from web servers to multiple internal A