AZ-700: Designing the Azure Network Foundation

Azure networking often fails long before a firewall rule is written. It fails when address ranges overlap during a merger, when applications rely on ad hoc name resolution, or when a route that looked harmless in one subscription diverts traffic from another. The foundational skill measured by Microsoft AZ-700 is the ability to design a network that remains understandable as workloads, teams and regions change. In the July 2026 objectives, core networking infrastructure accounts for 25–30% of the exam.

The exam expects more than familiarity with a virtual network diagram. It covers address planning, DNS, peering, routing, NAT, centralized network management and network visibility. It also evaluates practical selection of load-balancing services within the broader architecture. These pieces should not be memorized as independent product names. Their behavior depends on the same fundamental questions: which source can reach which destination, how the destination is named, which path the traffic takes and where controls are enforced.

Address planning is an organizational decision

An Azure virtual network has an address space, typically expressed in one or more CIDR ranges, and subnets carved from that space. A subnet represents an allocation and policy boundary for resources; it is not automatically a complete security perimeter. Azure reserves some addresses within each subnet for platform functions, so usable capacity is smaller than the mathematical total. Growth, private endpoints, gateway requirements and platform delegation should be considered before an address plan is frozen.

Consider a business allocating a /24 range to every environment because it is easy to remember. That may work for a small application but leave little room for private endpoints, platform services and future scale. Overlapping ranges become painful when independently built networks must communicate through peering, VPN or ExpressRoute. The logical layout should reflect expected connectivity and administrative boundaries rather than repeat a template simply because it is convenient.

A disciplined design establishes regional address reservations, workload allocations and rules for exceptions. The practical relationship between VLANs and subnet design helps candidates understand that logical separation and route policy are related but not identical. In Azure, the security outcome depends on NSGs, security admin rules, firewalls and application identities in addition to addresses.

Design subnets for the services that need them

Certain Azure services have dedicated subnet requirements, size guidance or delegation rules. A gateway subnet is not simply another place to deploy application virtual machines. Azure Bastion and firewall services also have deployment constraints, while some managed application platforms use delegated subnets. A valid design begins by identifying those requirements and reserving capacity rather than trying to retrofit them into a densely populated general-purpose subnet later.

Shared subnets may suit tightly related resources with the same trust level; dedicated subnets may suit separate operational ownership or distinct policy needs. But subdividing everything into tiny ranges can make future scale more difficult without improving isolation. The trade-off is between address flexibility, service constraints, policy clarity and ease of troubleshooting. Platform-subnet requirements should be checked against the current Microsoft documentation before implementation because they can change with service tiers or new features.

Subnet naming should carry purpose, not replace documentation. Labels such as “app-private” or “gateway” are useful only when supported by a network map showing ownership, intended traffic flows and dependency on other regions. Organizations maintaining hundreds of VNets benefit from repeatable allocation conventions and a centrally maintained source of truth.

Make DNS part of the design, not a final configuration task

Virtual networks can use Azure-provided DNS resolution or custom resolvers, but hybrid environments need a deliberate plan for internal and external namespaces. Azure DNS public zones answer public queries; private DNS zones resolve internal names to clients that can access the linked virtual networks, subject to the network and resolver configuration. Private DNS links are not the same thing as route connectivity. A correctly resolved private address is still unreachable if the path or security policy blocks it.

Azure DNS Private Resolver helps bridge resolution between Azure and on-premises systems without relying on custom DNS virtual machines for every use case. The important design questions are which client asks a question, which resolver receives it, which namespace is authoritative and what the client should receive. A private endpoint can be deployed successfully while applications continue reaching the service’s public address because DNS resolution was never updated.

Basic DNS concepts remain essential. DNS caching and TTL behavior explain why a change can appear correct to one client and stale to another. Good troubleshooting captures the exact name, returned address and resolver perspective before changing network rules. Fixing an apparent connectivity issue by widening a firewall may only conceal a name-resolution problem.

Peering creates connectivity, not automatic transit

VNet peering provides private connectivity between virtual networks through Azure’s backbone, subject to configuration and network policy. Peering relationships are not automatically transitive. If a hub is peered with two spokes, that does not itself mean the spokes can communicate through the hub. Routing through a gateway or network appliance, and the relevant peering settings, must be designed intentionally.

Gateway transit and the use of a remote gateway create further dependencies. A spoke may rely on a central gateway for access to on-premises networks, but address spaces, route advertisements and authorized paths must agree. A diagram showing lines between VNets is inadequate if it omits these effective routes. Teams should document which flows are direct, which traverse inspection and which are explicitly disallowed.

Peering also intersects with organizational governance. The network team might own the hub while application teams own their spokes. Without a review process, a harmless-looking change to peering or routing can create an unexpected path between workloads. Architecture must specify who can approve these changes and how the intended topology will be verified after deployment.

Know how Azure selects a route

Azure resources use system routes, and engineers can influence forwarding with user-defined routes and propagated gateway routes. The effective route depends on matching prefixes and applicable route selection rules; a more specific matching prefix can change the chosen path. A routing table associated with a subnet is therefore a policy decision that affects all participating workloads, not merely the virtual appliance shown on the diagram.

A default route to a firewall is often used to ensure outbound traffic receives inspection. The design must still consider platform requirements, access to private endpoints, asymmetric return paths and operational failure modes. A network may appear secure because all traffic is intended to traverse an appliance, yet become unavailable when a route loops or when the appliance cannot reach the intended destination. Understanding policy-based routing can provide useful background for how route decisions may be driven by explicit conditions; Azure UDRs follow their own documented route mechanics and should not be treated as direct copies of every traditional router feature.

Azure Route Server supports route exchange with compatible virtual appliances through BGP; it does not itself inspect or forward application packets. This distinction is important in diagrams where control-plane and data-plane components look similar. Candidates should be able to say which component advertises a route, which forwards packets and which enforces a security policy.

Treat outbound connectivity as a separate requirement

Applications often need outbound connections for software updates, partner APIs or identity services without needing public inbound exposure. A public IP address on every virtual machine is usually not the right answer. Azure NAT Gateway provides a managed outbound connectivity option associated with subnets and public IP resources. It should be selected with expected concurrency, source address requirements and service behavior in mind.

The difference between network address translation and routing is useful here. Translation changes address representation for traffic at a boundary; routing determines the forwarding path. A route toward a firewall and an outbound NAT design may both be needed, but they solve different problems. Observing that a request succeeds does not tell the operator which public identity it used or where its return path traveled.

For critical workloads, plan outbound behavior as carefully as inbound behavior. Some external partners allowlist source addresses. Unexpected changes in egress identity can break payment processing or supply-chain integrations without any application deployment. Ownership of outbound IPs, monitoring of connection failures and procedures for changing partner allowlists belong in the design record.

Use central management without concealing exceptions

Azure Virtual Network Manager can help manage connectivity and security admin configurations across groups of virtual networks. The opportunity is consistency: central policy reduces the risk that every workload team builds a different approximation of the same intended network. The challenge is scope. A centrally applied configuration can affect many services at once, so changes require validation, staged rollout and clear responsibility.

Security admin rules and local network security groups have different purposes and evaluation behavior. Teams should not assume that an NSG permits traffic that a higher-level rule denies, or that a central policy removes the need for application-specific restrictions. Configuration should be examined as an effective combination of controls. A diagram of the intended architecture is not evidence that every deployed subnet implements it correctly.

Automation improves repeatability when templates are reviewed, versioned and tested against expected resource relationships. It can also propagate a faulty CIDR allocation rapidly. Governance should include change review, drift detection and a way to explain exceptions without losing the benefits of a standardized network foundation.

Diagnose the path before changing production

When one application cannot reach another, start with a precise source, destination, port and observed failure. Confirm the resolved name and effective destination address. Check network reachability, the effective route, security rules and any dependency on a gateway or appliance. Only then decide which configuration needs to change. The sequence matters because a DNS error and an NSG deny may present similar symptoms to the application but require completely different fixes.

Azure Network Watcher provides tools to examine connectivity and routing, while Azure Monitor adds health and performance visibility. Neither substitutes for understanding the intended architecture. A flow log showing denied traffic may be evidence of a correctly enforced policy rather than a misconfiguration. Operators need to know what the flow was supposed to do before calling the denial an incident.

For AZ-700, a sound answer usually emerges from following the packet’s actual path. Addresses, names, routes, inspection and return traffic should fit into one coherent explanation. A well-built Azure network foundation makes that explanation possible even after the platform expands across subscriptions, teams and regions.