Microsoft AZ-104: VNets, NSGs and Private Endpoints

Azure networking is one of the easiest AZ-104 areas to underestimate because the individual components sound simple. A VNet provides address space, a subnet divides it, an NSG filters traffic, and a private endpoint gives a PaaS service a private IP address. The exam difficulty comes from how those pieces interact with routing, DNS, peering, service exposure, and troubleshooting.

Microsoft’s April 17, 2026 objectives for AZ-104 assign 15–20 percent of the exam to implementing and managing virtual networking. The outline explicitly includes virtual networks and subnets, peering, public IP addresses, user-defined routes, connectivity troubleshooting, NSGs, application security groups, effective rules, Bastion, service endpoints, and private endpoints.

The right way to study is to build a small network and make it fail in controlled ways. Networking becomes much easier when you can explain where a packet is supposed to go, which security control evaluates it, what name resolves to which address, and where the path breaks.

Address planning comes before security rules

A VNet is an IP address space, and subnets divide that space into usable network segments. Bad address planning creates problems that security controls cannot fix. Overlapping address spaces can prevent peering or complicate hybrid connectivity. Subnets that are too small can limit growth or specific services that require dedicated space.

Practice creating VNets with nonoverlapping CIDR blocks and several subnets that represent application tiers. Then connect VNets with VNet peering. Observe that peering connects networks but does not automatically make every topology transitive. Draw the traffic path rather than assuming that connected diagrams imply connected packets.

For AZ-104, you should be able to look at two address spaces and predict whether the design is viable before touching the portal. That basic skill prevents many downstream troubleshooting mistakes.

NSGs filter traffic at the subnet or network interface

Network security groups contain inbound and outbound security rules. They can be associated with subnets and network interfaces, which means a packet may be evaluated against more than one NSG. Effective security is the combined result of the applicable rules.

Study priorities, source and destination, protocol, port, and direction. Then practice with application security groups, which let you describe workloads logically rather than hard-coding individual IP addresses into every rule. The distinction between network security groups and application security groups becomes clearer when you build a three-tier application and change the membership of one tier.

A common troubleshooting mistake is to inspect only one NSG. Use effective security rules to see what is actually applied to a network interface. If a connection fails, determine whether the block is at the source subnet, destination subnet, NIC, operating system firewall, application, or another network device.

Routing decides where allowed traffic goes

An NSG can allow traffic and the connection can still fail because the route is wrong. Azure automatically creates system routes, while user-defined routes can send traffic through a virtual appliance or other next hop. Peering and gateway configurations also affect reachability.

Practice reading effective routes. Create a user-defined route that intentionally sends traffic to the wrong next hop, observe the failure, then correct it. This builds the habit of separating “is traffic allowed?” from “where is traffic being sent?”

That distinction is important in scenario questions. A security rule cannot repair a missing route, and a route cannot override a deny rule. Good troubleshooting isolates the layer rather than changing several settings at once.

Private endpoints change how a PaaS service is reached

A private endpoint is a network interface in your VNet with a private IP address that connects to a supported Azure service through Private Link. Instead of reaching the service over its public endpoint, clients can resolve the service name to the private address and keep the traffic on the private path.

This is useful for services such as Azure Storage, SQL Database, Cosmos DB, and Key Vault. But creating the private endpoint does not automatically prove that public access is disabled. The service’s own public network settings still matter.

Practice with one storage account. Create a private endpoint, verify its private IP, configure the appropriate private DNS zone, and test name resolution from inside the VNet. Then disable public network access and confirm that the intended private client still works while an external client does not.

DNS is often the real private-endpoint problem

Private connectivity depends on name resolution. An application usually calls the normal service hostname, not the private IP directly. DNS must resolve that hostname through the private-link zone to the private endpoint address.

If DNS resolves the public address, the application may bypass the private endpoint or fail once public access is disabled. If on-premises clients use custom DNS, conditional forwarding may be required so the private zone can be resolved correctly. Azure DNS knowledge becomes practical here because name resolution is part of the network path.

Make DNS troubleshooting a standard step. Use name-resolution tools before changing NSGs or routes. If the name points to the wrong IP, fix that problem first.

Service endpoints and private endpoints solve different problems

AZ-104 includes both service endpoints and private endpoints. A service endpoint extends the identity of a VNet subnet to a supported Azure service while the service still uses its public endpoint. A private endpoint places a private IP for the service inside the VNet.

That difference affects DNS, exposure, and architecture. Private endpoints are generally preferred when the requirement is private IP connectivity and the ability to disable public network access. Service endpoints can be simpler when the goal is to restrict a public service endpoint to selected VNets without introducing private-endpoint DNS.

Do not memorize one as universally better. Read the requirement. Does the service need a private IP? Must public access be disabled? Is the design trying to restrict access from a particular subnet? The scenario language usually reveals which capability is intended.

Peering, private endpoints, and DNS must work together

Many real environments place shared services in one VNet and applications in another. If an application in VNet A must reach a private endpoint in VNet B, peering, routing, and DNS all need to support the design. A correct private endpoint does not compensate for a missing peer or an unlinked DNS zone.

Build a two-VNet lab. Put the application client in one VNet and the private endpoint in the other. Peer the networks, link the private DNS zone appropriately, and confirm connectivity. Then remove one dependency at a time and record the symptom.

This is the kind of exercise that creates exam intuition. You stop seeing private endpoints as a wizard and start seeing them as part of a multi-layer network.

Troubleshoot in a fixed order

When connectivity fails, use a repeatable sequence. First verify name resolution. Second verify the destination IP and expected route. Third inspect effective routes. Fourth inspect effective NSG rules. Fifth check the target service’s firewall or public/private access configuration. Finally check the operating system and application layer.

Network Watcher can help with effective rules, IP flow verification, connection troubleshooting, and other diagnostics. Use the tools to gather evidence rather than changing settings randomly.

A simple troubleshooting notebook can be valuable. Record the source, destination name, resolved IP, route, NSG decision, destination service settings, and observed error. After several labs, common failure patterns become obvious.

Think like an administrator, not only a diagram reader

AZ-104 expects implementation and operation. You should know what a secure network looks like, but you should also be able to create it, change it, and diagnose it. A diagram that shows a VNet, NSG, and private endpoint is only the beginning.

Practice the administrative lifecycle: create the network, apply security rules, connect services, verify DNS, monitor behavior, introduce a fault, and restore connectivity. Azure networking material can deepen the design side, but keep AZ-104 focused on operational configuration and troubleshooting.

If you can explain a packet’s path from source to destination—including DNS, routing, NSG evaluation, peering, and the service’s private-access configuration—you have the level of understanding that makes AZ-104 networking scenarios far less intimidating.

Bastion helps separate administrative access from application exposure

Azure Bastion is another AZ-104 networking control worth practicing because it reduces the need to expose virtual machines directly through public RDP or SSH endpoints. Administrators connect through the managed service while the VM can remain reachable only on private addresses.

Use a lab to compare two designs. In the first, a VM has a public IP with an NSG rule for remote administration. In the second, remove the public IP and use Bastion. Identify how the attack surface changes, which NSG rules are still required, and how administrators reach the machine.

This reinforces a broader exam principle: networking controls are layered. Private addressing, NSGs, Bastion, routes, peering, and private endpoints solve different problems. Secure design comes from using the right combination rather than expecting one feature to provide complete isolation.

Before considering the lab complete, test it from more than one source. A connection from a VM in the same subnet can succeed while a peered VNet, on-premises client, or PaaS-integrated application still fails because the route or DNS path is different. Comparing those sources teaches you to avoid the assumption that one successful test proves the entire network design.

• Category: All Certifications Certifications