Microsoft AZ-104: Designing Azure Virtual Networks

Virtual networking is one of the most operational parts of the current Azure Administrator blueprint. The April 2026 AZ-104 objectives expect candidates to create virtual networks and subnets, configure peering and public IP addresses, work with user-defined routes, troubleshoot connectivity, secure networks with NSGs and application security groups, and choose between service endpoints and private endpoints. The AZ-104 exam therefore rewards administrators who can translate a workload requirement into a workable address, routing, and security design rather than simply recognize Azure networking product names.

The strongest way to prepare is to think in layers. Addressing determines where resources live. Routing determines where packets can go. Security controls decide what traffic is permitted. Name resolution helps applications find destinations. Private access features change how platform services are reached. Troubleshooting becomes easier when these layers are separated instead of treated as one large “networking problem.”

Start with address space and subnet boundaries

A virtual network needs an address space large enough for the resources it will contain, while its subnets divide that space into administrative and security boundaries. Poor planning can create overlap that later blocks peering or forces disruptive readdressing. It can also leave no room for application growth, private endpoints, gateways, or other services that consume addresses. Administrators should be comfortable reading CIDR notation and reasoning about whether two ranges overlap; a deeper refresher on CIDR and subnet sizing is useful because the exam often embeds networking arithmetic inside an Azure scenario.

Do not treat subnets as cosmetic folders. A subnet is a place where route tables, network security groups, private resources, and service integrations can be applied. Separating web, application, management, and data tiers can make access rules clearer and reduce the blast radius of a mistake. At the same time, excessive segmentation creates operational overhead. The exam typically favors the simplest structure that meets the stated isolation, scale, and management requirements.

One useful design habit is to reserve address capacity before deployment. If a scenario says that a virtual network must later peer with another environment or add a large scale set, the administrator should think about future address demand before choosing a narrowly sized prefix. Azure cannot magically make overlapping networks routable just because the resources are in different subscriptions.

Use NSGs and application security groups for policy, not topology

Network security groups filter traffic with ordered security rules. They can be associated with subnets and network interfaces, and the effective result can reflect both locations. Application security groups make rule authoring easier by grouping network interfaces according to application role instead of hard-coding many individual addresses. That is a policy layer: the virtual network and subnet create the topology, while NSGs decide which flows are allowed or denied.

When analyzing a failed connection, avoid immediately adding a permissive inbound rule. First inspect the source, destination, protocol, port, priority, and direction. Then check whether a rule on the subnet and a rule on the NIC combine to block the flow. The general logic is similar to working with network access control lists: a precise rule is safer than a broad exception, and rule order matters.

Application security groups are most valuable when the requirement is expressed in application terms such as “web servers may reach database servers on a specific port.” They reduce dependence on changing IP addresses, but they do not replace subnet planning or routing. A common exam trap is to use the right security feature for the wrong problem.

Understand what virtual network peering does and does not do

Peering connects virtual networks so that resources can communicate over the Azure backbone using private addressing. It is often used when teams want separate network boundaries without placing every workload into one large virtual network. A hub-and-spoke design can centralize shared services while keeping application networks separated; the broader hub-and-spoke topology concept helps explain why this pattern is so common.

The important exam lesson is that peering is a connection, not a universal routing solution. Address ranges must not overlap. Administrators must consider whether forwarded traffic, gateway use, and routes support the desired path. Peering relationships also need to be evaluated from both network sides rather than assumed to be transitive through an intermediate VNet.

When a scenario contains several networks, draw the intended communication path mentally before choosing a configuration. Ask which virtual networks need direct reachability, which services should be centralized, and whether a route or security rule would still prevent traffic after peering is created. This keeps the decision grounded in packet flow rather than architecture buzzwords.

Choose private access deliberately

Azure administrators frequently need platform services to be reachable without exposing them unnecessarily to public networks. Service endpoints and private endpoints solve related but different problems. A service endpoint extends the identity of a selected virtual network subnet to a supported Azure service. A private endpoint creates a network interface with a private address in the virtual network and maps access to a specific service resource through Private Link.

For exam scenarios, focus on the requirement. If the application must reach a PaaS resource through a private IP and public access should be reduced or disabled, a private endpoint is usually the more natural fit. If the requirement is to restrict service access to approved subnets without giving the service a private endpoint in the VNet, a service endpoint can fit. DNS becomes important with private endpoints because the client must resolve the service name to the private address.

These features do not remove the need for identity and authorization. Private connectivity answers how traffic reaches the service. It does not by itself decide which user or workload is allowed to read data once the connection is established.

Control packet paths with routes and public addressing

Azure creates system routes automatically, but administrators can add user-defined routes when traffic must follow a specific next hop such as a network virtual appliance. A route table is therefore a traffic-engineering tool, not an access-control list. If the requirement says “send traffic through this firewall,” think routing. If it says “deny this source and port,” think security rule. The conceptual difference mirrors traditional static routing, where the administrator deliberately determines a path.

Public IP addresses matter when a resource or service needs internet-reachable addressing, but AZ-104 questions often reward designs that minimize unnecessary public exposure. Azure Bastion is specifically listed in the blueprint because it can provide managed administrative access to virtual machines without requiring a public IP on every VM. That reduces the number of management endpoints exposed to the internet.

When routing seems wrong, inspect the effective route table rather than relying on what you intended to configure. System routes, peering, user-defined routes, and service-specific behavior can all influence the observed path. A correct design is one whose effective route matches the application requirement.

Troubleshoot connectivity in a fixed order

Connectivity incidents become manageable when diagnosis follows a sequence. Confirm source and destination addressing first. Check whether the expected DNS name resolves correctly. Verify routes and peering. Inspect NSG effective rules. Confirm the destination service is listening and that any platform firewall or private-access setting allows the connection. Finally, use Azure Network Watcher and connection-monitoring capabilities when the path still is not obvious.

This order helps avoid random configuration changes. If name resolution points to the wrong address, changing an NSG will not fix the root cause. If the route sends traffic to an appliance that has no return path, adding a public IP will not solve it. The exam often supplies enough evidence to identify the failing layer if you resist the urge to jump straight to a product feature.

Operational networking also means documenting the intended path. A logical network diagram, address plan, security rule set, and route design make future troubleshooting faster. Even when a question does not ask for documentation, thinking as if you had to explain the packet path to another administrator improves answer quality.

Keep administration separate from architecture design

AZ-104 is an administrator exam, so the focus is implementing and managing networks rather than producing an enterprise architecture from first principles. Candidates preparing for AZ-305 may encounter broader design trade-offs, but AZ-104 scenarios usually give enough context to select a subnet, peering relationship, route, NSG, Bastion deployment, or private-access method and then operate it correctly.

A useful exam decision sequence is: identify the required communication, locate the source and destination networks, check address compatibility, determine the route, apply the narrowest security control, and then decide whether access should be public, service-restricted, or private. After that, consider how you would validate the effective configuration. This sequence mirrors real troubleshooting and prevents feature-first guessing.

Virtual networking is not difficult because any single Azure feature is unusually complex. It is difficult because several independent controls can affect the same connection. Master the boundaries between addressing, routing, security, private access, and DNS, and the networking portion of AZ-104 becomes much more predictable.

Leave room for growth and platform dependencies

Address planning should include more than the VMs visible in the first diagram. Private endpoints, gateways, scale-out instances, managed services, and future subnets can all consume address space or impose subnet requirements. A design that uses nearly every available address on day one can turn a routine expansion into a readdressing project. Reserve sensible capacity and keep adjacent ranges available when the business is likely to grow.

Also pay attention to service-specific subnet requirements. Some Azure services need dedicated subnets or have restrictions on delegation and network policy. AZ-104 is not asking you to memorize every service limit, but it does expect an administrator to recognize that a subnet is an operational boundary with consequences. When a deployment fails because the selected subnet cannot support the requested service, adding a security rule will not solve it.