Virtual networking for Microsoft AZ-104 Azure Administrator: Concepts, Scenarios, and Study Priorities

 

Azure networking is one of the easiest AZ-104 areas to overcomplicate because several controls can influence the same failed connection. A request can fail because name resolution returns the wrong address, a route sends traffic to the wrong next hop, an NSG denies the flow, a private endpoint is associated with the wrong network or DNS zone, a load balancer considers the backend unhealthy, or the destination service rejects the request for an identity or application reason. Changing random settings until traffic works is not troubleshooting.

The current April 17, 2026 AZ-104 blueprint assigns 15–20 percent to virtual networking. It includes virtual networks and subnets, peering, public IP addresses, user-defined routes, connectivity troubleshooting, NSGs, application security groups, effective security rules, Azure Bastion, service endpoints, private endpoints, Azure DNS, internal and public load balancers, and load-balancing troubleshooting. Microsoft also places Network Watcher and Connection Monitor in the monitoring domain, which reinforces the need to use evidence rather than guesses.

The most reliable study model is a packet-path model: resolve the name, identify the destination address, determine the route, evaluate network security, confirm the destination or load-balancer health, and then validate the application or service authorization layer. The networking practice set is most useful after you can apply that sequence without relying on portal navigation.

Troubleshoot networking as a sequence of evidence

A failed Azure connection should be reduced to a small number of testable questions:

1. Name resolution: What name is the client using, and what address does it resolve to?
2. Source and destination: Which IPs and subnets are actually involved?
3. Routing: What next hop will Azure select? Is a user-defined route or peering relationship changing the path?
4. Network security: Which NSG rules are effective on the relevant subnet or NIC? Is an application security group changing the rule target?
5. Service exposure: Is the destination public, behind a load balancer, or reachable through a private endpoint?
6. Health: If load balancing is involved, is the backend considered healthy by the probe?
7. Application or authorization: If the network path succeeds, does the application or PaaS service still reject the request for a non-network reason?

Network Watcher and Connection Monitor can provide evidence for several of these steps. The key is to avoid making three configuration changes before you know which layer is failing. A disciplined sequence preserves causality: one hypothesis, one check, one change, one retest.

Addressing, subnets, peering, and routes

Think in paths before thinking in features

A virtual network by itself does not guarantee connectivity. A successful connection depends on address space, subnet configuration, name resolution, routes, security rules, service configuration, and the health of the destination.

When a scenario says, “VM1 cannot reach Storage1,” do not immediately change an NSG. Draw the path. Does the hostname resolve? What address does it resolve to? Is the destination public or private? Which route applies? Does an NSG allow the traffic? Does the storage account permit the source network? Does the identity have data access? The networking layer is only one part of the dependency chain.

This approach is especially useful on AZ-104 because answer choices often include several plausible networking controls. A path model tells you which control actually owns the symptom.

Virtual networks define private address space in Azure

An Azure virtual network provides a private networking boundary where resources can communicate according to configured address spaces, subnets, routes, and security rules. The important skill is not simply creating a VNet. You need to choose address spaces that support current and future connectivity requirements.

Address-space overlap can prevent or complicate connections between networks. If two VNets must be peered, overlapping prefixes are a problem. If Azure will connect to on-premises networks, the cloud address plan should avoid conflicts with the existing enterprise network.

Practice designing a small environment before deploying it. Allocate one VNet for production and another for management or testing, then choose nonoverlapping subnets for web, application, data, and administrative workloads. The exact ranges matter less than the discipline of planning them deliberately.

Subnets are segmentation and control points

Subnets divide a VNet address space and provide useful boundaries for routing, security, service integration, and workload organization. A subnet does not automatically create isolation by itself; isolation comes from the controls applied to the path.

Use subnets to group resources with similar network requirements. For instance, web front ends may require inbound access from a load balancer, while backend systems accept traffic only from application subnets. Management access may be routed through Bastion rather than direct public exposure.

When studying subnets, practice calculating whether the chosen prefix leaves enough addresses for the workload and whether a new subnet overlaps an existing one. AZ-104 is not a pure subnetting exam, but poor IP planning creates downstream networking problems.

Public IP addresses create internet-reachable endpoints where appropriate

A public IP address can provide a publicly routable endpoint for Azure resources or load-balancing front ends. The exam may test whether a public address is required, which resource should own it, or whether the design should avoid public exposure entirely.

Avoid assuming every VM needs a public IP. Secure administrative access can use Azure Bastion, and application traffic can enter through a load balancer or other application delivery service. A design with fewer direct public endpoints is often easier to secure and operate.

In scenarios, identify whether the requirement says “reachable from the internet” or merely “administrators must connect remotely.” Those are different needs.

Virtual network peering connects Azure VNets

Peering allows resources in different Azure virtual networks to communicate over the Azure backbone when configuration and addressing permit it. The networks remain separate VNets, but they can exchange traffic as if connected through a routed relationship.

A common exam mistake is assuming peering is automatically transitive. If VNet A peers with B and B peers with C, that does not automatically mean A and C can communicate through B as if a full mesh existed. Additional routing or network-virtual-appliance design may be required depending on the architecture.

Practice creating two small VNets with nonoverlapping address spaces and peer them. Verify connectivity. Then add a third VNet and reason about which communication paths exist. This exercise teaches more than memorizing the term “peering.”

User-defined routes change where traffic goes

Azure provides system routes automatically, but user-defined routes can alter traffic paths. A route table can be associated with a subnet and specify address prefixes with next-hop behavior.

This is a major troubleshooting area. If traffic should pass through a virtual appliance but does not, inspect the effective routes. If traffic unexpectedly leaves through another path, ask whether a UDR overrides the expected system behavior. The correct route must match the destination prefix and specify an appropriate next hop.

Do not confuse routing with security. A route determines where traffic goes. An NSG determines whether traffic is allowed according to its rules. A packet can have a perfectly valid route and still be denied by security, or it can be allowed by security but sent to the wrong next hop.

Network security and administrative access

Network security groups evaluate traffic rules

NSGs contain inbound and outbound security rules with priorities, sources, destinations, protocols, and ports. They can be associated with subnets and network interfaces. The important exam skill is evaluating which rule actually applies.

When troubleshooting an NSG, read the rules in priority order and consider both custom and default behavior. A broad allow rule can be overridden by a higher-priority deny. A rule applied at the subnet and another at the NIC can both affect traffic.

Practice with a simple scenario: allow HTTPS from a specific source, deny an unwanted management port, and verify the result. Then add a conflicting rule with a different priority and predict the effective outcome before testing.

The networking practice is useful after you can evaluate rules from the scenario rather than by guessing from service names.

Application security groups simplify rule targeting

Application security groups let you group network interfaces logically and reference those groups in NSG rules. This can make security rules easier to understand than using many individual IP addresses.

Imagine several application servers and several database servers. Instead of writing rules tied to specific addresses, an ASG-based rule can express “application tier may reach database tier on this port.” The rule reflects the workload role rather than the current IP assignment.

For AZ-104, focus on the relationship: ASGs are used inside NSG rules to identify groups of resources. They do not replace NSGs, and they do not route traffic.

Effective security rules help explain unexpected access

In real environments, a VM’s traffic can be affected by NSGs on both its subnet and network interface. Effective security rules provide a way to understand the combined rule evaluation for a network interface.

When a scenario says “the configured NSG rule looks correct, but traffic is still blocked,” inspect whether another associated NSG contributes a deny. This is a classic example of why administrators need to evaluate effective state instead of looking at one object in isolation.

Use this same principle throughout Azure: effective access, effective routes, and effective security are often more useful than the configuration you most recently changed.

Azure Bastion provides managed administrative access

Azure Bastion allows RDP or SSH connectivity to virtual machines through the Azure portal and the Bastion service without requiring each VM to expose a public IP for direct management. That makes it a valuable option when a requirement emphasizes secure administrative access without public management ports.

Do not confuse Bastion with a general-purpose application load balancer or VPN service. Its purpose is administrative connectivity to VMs. In a scenario, look for phrases such as “connect to Azure VMs without exposing RDP or SSH directly to the internet.”

A practical exercise is to deploy a VM without a public IP and connect through Bastion in a lab environment. Even if you do not complete the full deployment, diagram the path and identify which subnet and service configuration are involved.

Private access to Azure PaaS

Service endpoints extend VNet identity to supported PaaS services

Service endpoints allow a subnet to establish a direct optimized route to supported Azure services while the service still uses its public endpoint model. The PaaS service can then restrict access to selected virtual-network subnets.

The exam-relevant idea is that the client remains in a VNet and the service can trust or permit that subnet relationship. The service itself does not receive a private IP in your VNet because of a service endpoint.

This distinction becomes important when comparing service endpoints with private endpoints.

Private endpoints place a private service address in the VNet

A private endpoint creates a network interface with a private IP address in your VNet that represents a supported PaaS service through Azure Private Link. Traffic can then reach the service through private addressing rather than the public endpoint path.

The networking configuration alone is not enough. DNS must resolve the service name to the private IP for clients intended to use the private path. This is one of the most important troubleshooting patterns in Azure networking.

If a private endpoint exists but clients still resolve the service name to a public address, traffic may not follow the intended route. Always include DNS in private endpoint reasoning.

The storage guide provides storage-specific examples of this pattern.

Service endpoint versus private endpoint: use the requirement language

A useful comparison is:

• service endpoint: keep access restricted to selected VNet subnets while the service is still represented through its public endpoint architecture;
• private endpoint: expose the service through a private IP address in the VNet.

When a scenario explicitly requires private IP connectivity, private endpoint concepts are usually central. When the requirement is to restrict service access to a selected subnet without requiring a private service address, service endpoints may fit.

Do not treat one as universally “more secure.” The correct choice depends on the design requirement, supported service, DNS model, cost, and operational complexity.

DNS and load balancing

Azure DNS provides name resolution for Azure-hosted zones

Azure DNS can host public or private DNS zones. For AZ-104, understand the administrative role of zones, records, and name resolution rather than trying to memorize every record type.

A DNS record maps a name to an address or another name according to the record type. If an application reaches a service by hostname, DNS is part of the dependency chain. A network can have correct routes and NSGs while the application still fails because the hostname resolves incorrectly.

Practice creating a test record and validating it. For private endpoint scenarios, pay particular attention to private DNS zones and how VNet clients obtain the private address.

DNS troubleshooting should happen early

When a user says, “I can connect by IP but not by name,” DNS immediately becomes a primary suspect. When private service access unexpectedly uses a public path, check name resolution. When a custom application domain points to an old endpoint, network controls may be entirely correct.

A disciplined process is:

1. identify the exact hostname the application uses;
2. query or inspect the resolved address;
3. compare it with the expected public or private target;
4. identify which DNS zone or resolver supplied the answer;
5. correct the record or zone linkage before changing unrelated network controls.

This prevents hours of random NSG editing when the real problem is name resolution.

Load balancers distribute traffic to backend resources

Azure Load Balancer provides layer-4 load balancing for TCP and UDP traffic. The current AZ-104 objectives include configuring internal or public load balancers and troubleshooting them.

Think of a load-balancer configuration as several connected elements: front-end IP configuration, backend pool, health probe, and load-balancing rule. If any of these are wrong, traffic may not reach the intended backend.

A public load balancer has a public front-end endpoint. An internal load balancer uses a private front-end address within a VNet. The requirement determines which fits.

Health probes are critical to load-balancer behavior

A load balancer should send traffic only to healthy backend instances according to its health probe. If a backend is not responding on the probe’s configured protocol or port, it may be removed from rotation even if the VM itself is running.

When troubleshooting, do not stop at “the backend VM is powered on.” Check whether the application listens on the expected port, whether the probe reaches it, whether NSG rules permit the probe and traffic, and whether the backend pool contains the correct interfaces or instances.

This is another example of effective state being more important than one visible configuration page.

Diagnostic tools and troubleshooting

Use Network Watcher and Connection Monitor as evidence tools

The current AZ-104 monitoring objectives include Network Watcher and Connection Monitor. These tools belong naturally in networking troubleshooting because they help administrators validate connectivity and inspect network behavior.

Do not memorize them as isolated monitoring terms. Use them in a troubleshooting story. If two resources cannot communicate, use a connectivity tool to gather evidence. If the path is healthy, investigate DNS, application, or authorization layers. If the path is not healthy, inspect routes and security controls.

This connects the networking domain to the exam-day guide only conceptually; for study, the important point is that network troubleshooting should produce evidence before changes.

Build a repeatable networking troubleshooting checklist

Use this sequence when a connection fails:

6. Define source, destination, protocol, and port.
7. Confirm the source and destination IP configuration.
8. Resolve the hostname and compare the result with the intended endpoint.
9. Review effective routes from the source subnet or NIC.
10. Review effective security rules.
11. Check service-specific firewalls or private connectivity settings.
12. Confirm the destination is healthy and listening.
13. Use Network Watcher or Connection Monitor when useful.
14. Change one setting at a time.
15. Retest the original flow.

This sequence is more reliable than jumping to the feature whose name appears in the question.

Analyze AZ-104 compute scenarios

Scenario 1: private VM administration

Requirement: administrators must manage Azure VMs using RDP or SSH, but the VMs must not have public IP addresses and management ports must not be directly exposed to the internet.

Azure Bastion is a strong fit because it provides managed administrative connectivity to private-addressed VMs. You would still design NSGs and user access appropriately, but the key requirement is secure remote management without direct public exposure.

A public load balancer does not solve administrative access. A private endpoint is not for VM RDP/SSH. Recognizing the service’s primary job eliminates distractors.

Scenario 2: traffic between two VNets

Requirement: application resources in VNet A need private connectivity to database resources in VNet B. The address spaces do not overlap.

VNet peering is a straightforward Azure-native option. Configure peering and then confirm NSGs, routes, and application listening behavior permit the intended flow.

If the scenario adds a third VNet and assumes traffic should pass through the second, revisit the nontransitive behavior of basic peering and determine whether additional connections or routing design are required.

Scenario 3: force outbound traffic through a security appliance

Requirement: workloads in a subnet must send traffic for a particular destination through a network virtual appliance.

A user-defined route associated with the subnet can direct the destination prefix toward the appliance as the next hop. The appliance must be configured to forward traffic, and NSGs must permit the flow.

The key distinction is that the UDR changes the route. An NSG alone cannot direct traffic through an appliance.

Scenario 4: private access to an Azure PaaS service

Requirement: a workload must access a supported Azure PaaS service through a private IP address, and the public service endpoint should not be the normal application path.

This points toward a private endpoint. Plan DNS so the normal service hostname resolves to the private address for the workload. Then validate the network path and service authorization independently.

If access fails, check DNS before changing security controls blindly.

Scenario 5: internal application load balancing

Requirement: several backend VMs should receive TCP traffic from clients inside the VNet through one stable private address. The service should not be internet-facing.

An internal Azure Load Balancer fits. Configure a private front-end IP, backend pool, health probe, and rule. Ensure NSGs permit client and probe traffic.

Troubleshooting should confirm whether the front-end responds, whether backends are healthy, and whether the application listens on the expected port.

Scenario 6: NSG rule appears correct but traffic still fails

Requirement: an administrator added an inbound allow rule to a VM’s NIC NSG, but traffic is still blocked.

Inspect all relevant NSGs, including any subnet-level NSG, and evaluate effective security rules. Check rule priority and direction. Confirm that routing and the application listener are also correct.

The lesson is that one correct rule does not prove the entire path is allowed.

A practical networking lab sequence

Stage 1: VNet and subnet basics

Create a VNet with at least two subnets and deploy small test resources. Verify communication and note the default behavior.

Stage 2: NSGs and ASGs

Add NSG rules that allow only required traffic. If possible, use application security groups to target workload roles. Predict rule evaluation before testing.

Stage 3: peering and routing

Create another VNet, peer it, verify connectivity, and then add a UDR that changes one traffic path. Observe the effective route.

Stage 4: secure administration

Deploy or study Azure Bastion and compare the design with direct public RDP or SSH access.

Stage 5: PaaS connectivity

Configure a service endpoint or private endpoint scenario. For private endpoints, verify DNS resolution explicitly.

Stage 6: DNS and load balancing

Create DNS records, configure an internal or public load balancer, and validate backend health and traffic flow.

Stage 7: troubleshooting

Break an NSG rule, route, DNS record, or backend probe and diagnose the symptom without checking the intentional change first.

Capstone: trace the complete path

Draw the path on paper before you configure it

A simple diagram is one of the fastest ways to improve AZ-104 networking judgment. Draw the client, subnet, VNet, DNS answer, route, NSG, service endpoint or private endpoint, load balancer if present, and destination. Put arrows between them and annotate which control can allow, deny, translate, or redirect traffic.

Now take a scenario that says a VM in SubnetA cannot reach a storage account privately. If DNS resolves the storage name to a public address, the private endpoint may be configured correctly while the client still uses the wrong destination. If DNS resolves to the private address but the route is wrong, the issue is different. If the route is correct but the storage account rejects the network, investigate the service configuration. If the network path works but access returns an authorization error, move to identity and data permissions.

The diagram keeps you from solving the wrong layer. It also helps with load balancing. Draw the front-end IP, rule, health probe, backend pool, NSGs, and application port. A failed probe can make a backend unavailable even when normal client routing is correct. A correct probe does not guarantee the application’s DNS name points to the front end.

Repeat the drawing exercise until you can build the path from memory. The visual habit is especially useful under exam pressure because it converts a long paragraph into a small set of relationships.

Capstone scenario: multi-tier application with private dependencies

Design a three-tier application with a public web front end, private application tier, and a PaaS storage dependency. Internet clients should reach only the web entry point. The application tier should accept traffic only from the web tier. The storage service should be reachable through private connectivity, and administrators should manage VMs without exposing RDP or SSH directly.

Start with address spaces and subnets. Decide where each workload belongs and ensure enough room for growth. Use NSGs to express the permitted flows between tiers. If the web front end uses a load balancer, configure the front-end address, backend pool, health probe, and rule. Use Bastion for administration. Add a private endpoint for storage and make sure DNS maps the service name to the private IP from the application network.

Then add an operational change: route outbound application traffic through a network virtual appliance. Create a user-defined route for the relevant destination and confirm the next hop. Ask how this affects return traffic and what the appliance must do to forward packets.

Finally, break three items one at a time: change the storage DNS record, add a higher-priority NSG deny, and make the load-balancer health probe target the wrong port. For each failure, start from the user-visible symptom and use the troubleshooting checklist rather than immediately inspecting the setting you changed.

This capstone combines most of the networking domain while reinforcing the idea that each control has one primary job.

Practice “which control owns this?” questions

During final review, turn every networking term into a control-ownership question. Which control decides whether traffic is allowed? NSG. Which control changes the next hop? Route. Which service provides managed RDP or SSH access without a public IP on the VM? Bastion. Which component gives a PaaS service a private IP in the VNet? Private endpoint. Which system maps a hostname to an address? DNS. Which load-balancer element decides whether a backend is healthy? Health probe.

Then combine the questions. A client resolves the right address but traffic is denied: DNS is probably not the primary problem. A client can reach the load-balancer front end but receives no response: inspect backend health, rule configuration, NSGs, and the application listener. A VM has Contributor on a storage account but private access fails: role assignment may not solve the network path.

This ownership method keeps concepts distinct without requiring artificial memorization. It also makes cross-domain scenarios easier because you can quickly identify when the real issue belongs to identity, storage, compute, or monitoring rather than networking.

Common networking mistakes

Watch for these patterns:

• assuming a subnet itself creates isolation;
• using an NSG to solve a routing problem;
• using a route to solve an authorization problem;
• assuming VNet peering is automatically transitive;
• ignoring address-space overlap;
• overlooking NSGs at both subnet and NIC scope;
• ignoring rule priority;
• treating Bastion as general application connectivity;
• confusing service endpoints with private endpoints;
• creating a private endpoint without planning DNS;
• assuming a healthy VM means a load-balancer backend is healthy;
• forgetting to check the application listening port;
• opening public access when a private design would satisfy the requirement.

The AZ-104 mistakes can help you identify whether these errors come from study habits or specific networking knowledge gaps.

Final networking checklist

Before considering the networking domain ready, Be ready to:

• design nonoverlapping VNet and subnet address spaces;
• create and reason about VNet peering;
• understand when a public IP is and is not required;
• explain user-defined routes and inspect effective routes;
• evaluate NSG rules by priority, direction, source, destination, protocol, and port;
• explain the purpose of application security groups;
• use effective security rules when multiple NSGs apply;
• explain when Azure Bastion fits a secure-management requirement;
• distinguish service endpoints from private endpoints;
• include DNS in private endpoint troubleshooting;
• configure or reason about Azure DNS records and zones;
• explain the components of internal and public Azure Load Balancers;
• troubleshoot backend health, probes, NSGs, and application listeners;
• use a path-based troubleshooting method rather than random configuration changes.

Use the AZ-104 exam only after the underlying path model is strong enough to explain why an answer works. Networking questions become far easier when you can trace the packet, identify the control at each stage, and verify each assumption with evidence.

Virtual networking is not a collection of acronyms. It is a system of addresses, names, routes, security rules, endpoints, and healthy destinations. Build your AZ-104 preparation around that system, and unfamiliar scenarios become structured troubleshooting problems rather than guesswork.