An enterprise migrates three business applications into Azure and gives each one a virtual network. The applications work individually, but the company soon needs shared DNS, centralized inspection, access to on-premises services, and consistent internet egress. Its network engineers propose a hub-and-spoke architecture. The diagram looks simple: one hub, three spokes, and a handful of lines. The implementation is less simple because virtual network peering, route tables, appliances, private endpoints, and DNS resolvers must behave consistently across security and failure boundaries.
Candidates studying Microsoft AZ-700 should treat hub-and-spoke networking as a design problem rather than a peering tutorial. Microsoft’s July 2026 skills outline covers core network infrastructure, hybrid access, private connectivity, application delivery, security, and operational monitoring. Those topics meet in real hub-and-spoke deployments. The objective is to allow intended traffic while making unintended paths difficult to create and easy to detect.
Decide which services belong in the hub
A hub virtual network often hosts shared network infrastructure such as firewalls, gateways, DNS forwarding, or common connectivity to on-premises. Spokes isolate application environments or teams. This arrangement can simplify policy enforcement when many workloads need the same controls. It can also turn the hub into a central dependency whose outage affects everyone. Define what is truly shared and what ought to remain local to each workload.
Consider an HR application that processes confidential employee data and a public web analytics environment with less restrictive network requirements. They may share corporate connectivity while needing different inspection or egress rules. Placing both inside one spoke defeats some of the isolation expected from the architecture. Conversely, creating a separate spoke for every minor component can complicate route management and raise cost. Boundaries should follow data ownership, operational risk, and delegated responsibility.
Document IP address planning before peering. Overlapping address ranges prevent straightforward routing and make future connectivity difficult. Address space is especially important when an acquisition, regional expansion, or on-premises migration will add networks later. The cheapest time to avoid an overlap problem is before applications bind private addresses into configuration and firewall rules.
Understand peering without assuming transit
Azure virtual network peering establishes connectivity between virtual networks, subject to routing and security configuration. It does not automatically make the hub a transit router that connects all spokes through itself. Engineers must design any required transit behavior using supported routing, gateway transit, user-defined routes, and forwarding components. Expecting two spokes to communicate through a hub merely because both are peered to it is a common architectural misunderstanding.
A centrally managed firewall may inspect traffic between spokes if routes intentionally direct that traffic through it and forwarding is supported. Route symmetry matters when a stateful appliance must observe both directions of a session. If one direction passes through inspection and the return path bypasses it, legitimate connections may fail unpredictably. Review effective routes on relevant network interfaces rather than relying solely on topology diagrams.
Peering choices also affect cost and change propagation. A large network can accumulate many peerings, and the operational task is not just creating connections but managing permissions, names, ownership, and changes. Azure Virtual Network Manager may be useful when a large estate needs centralized connectivity patterns. Its capabilities should be evaluated against the network’s scale and governance requirements, not assumed necessary for every small deployment.
Use route tables to express intended paths
User-defined routes can direct traffic toward a virtual appliance or other supported next hop. This is often required when the organization wants centralized inspection or controlled egress. Routes must be consistent with system routes, peering behavior, gateway propagation, and destination prefixes. A default route to a firewall can protect general internet-bound flows while still allowing specific private service paths under separately designed conditions.
Changing a route can have a much broader effect than changing one application’s code. If a shared route table is associated with dozens of subnets, a mistaken next hop can interrupt many services simultaneously. Use infrastructure-as-code review, staged changes, connectivity tests, and clear rollback procedures. Route policies should have named owners and operational explanations, not just a collection of prefixes whose purposes are forgotten.
Designers should check asymmetric paths carefully when hybrid connectivity is present. An on-premises destination may be reachable through one gateway, while a spoke sends return traffic through a different firewall path. This can create problems that appear only for certain subnets or after a failure. Network Watcher tools and effective route inspection help establish the path Azure actually uses for a particular interface and destination.
Integrate DNS as part of the connectivity design
Private name resolution is not an optional finishing touch. Applications reach services by names, and those names may need to resolve to private endpoint addresses, virtual machine addresses, or on-premises hosts depending on where the request originates. A spoke that can route to an IP address but resolves the hostname to a public endpoint will not behave as the design intended.
Plan which DNS zones are authoritative, how Azure-hosted workloads query them, how hybrid forwarding works, and which networks are linked to relevant private DNS zones. Shared resolvers can help centralize rules, but they must be resilient and appropriately reachable. Changes to conditional forwarding can affect unrelated applications if teams treat DNS as a network-only service rather than a cross-platform dependency.
Troubleshooting must distinguish resolution from reachability. First check the name and returned record, then test route and security decisions for the returned destination. A successful lookup does not mean that an NSG, firewall, or private endpoint connection allows the traffic. Likewise, a network path that appears healthy at the IP level can still produce application failures when TLS hostnames or certificates do not match the address selected by DNS.
Define security at the appropriate layers
Network security groups can enforce traffic rules at supported subnet or interface boundaries; central firewalls can provide broader inspection or application-aware policy where configured. These controls serve different purposes. An NSG that denies unnecessary lateral traffic between workload subnets may reduce exposure even when a hub firewall also exists. Relying on only one central appliance can leave other paths insufficiently constrained.
Segmentation policies should follow application communication maps. A payroll database should accept traffic from designated services, not every network peered to a hub. Security teams and application owners need agreement about required ports, protocols, destinations, and change processes. Broad ‘allow virtual network’ rules may be convenient during testing but can undermine the segmentation the architecture was intended to create.
Logging needs corresponding design. If inspection occurs in several places, security events must be correlated with workloads and route decisions. A blocked flow might indicate a misconfiguration, a new deployment, or suspicious behavior; operators need enough context to tell the difference. Align network policy with the broader Microsoft cybersecurity architecture approach to Zero Trust and layered protection, but do not conflate network location with authorization to business data.
Keep the hub available without pretending it cannot fail
A centralized transit appliance or gateway can become a shared failure point. Availability-zone support, redundant instances, load balancing, and service-specific resilience capabilities may reduce that risk, but designers must verify the behavior of the exact deployment. Multi-region continuity is a separate architectural problem involving routing, DNS, application state, and data replication. A hub spanning an impressive diagram does not make an application fault tolerant by itself.
Capacity planning should account for east-west traffic, hybrid transfers, and internet egress that pass through central resources. A firewall sized for initial applications may later become a bottleneck when additional spokes move production workloads into the estate. Bandwidth and latency matter as much as route reachability. Measure actual flows and model growth before committing every spoke to the same dependency.
Failure tests should cover an appliance loss, a peering change, gateway impairment, DNS resolver unavailability, and an accidental route update. Test from representative workloads and inspect both forward and return paths. The exercise should confirm not only restoration time but also whether alerts identify the failing component. An architecture that recovers eventually yet takes hours to diagnose may still fail the organization’s service objective.
Operate hub-and-spoke as a managed network
Treat spoke onboarding as a product with a documented process: address allocation, required peerings, DNS registration, routing, segmentation rules, monitoring, and ownership. Automate repeatable steps but retain approval for high-blast-radius changes. A new application team should understand which central services it inherits and which responsibilities remain local. Otherwise, the initial governance gains can dissolve as teams deploy exceptions that are poorly documented.
Review the architecture whenever connectivity demands change. A new region, partner connection, acquisition, or sensitive workload may justify another hub or a different connectivity model such as Azure Virtual WAN. The relevant Azure administrator responsibilities include keeping resources configured and monitored, while AZ-700 focuses on the network decisions that connect them. Use current traffic and risk evidence, not loyalty to an earlier diagram.
The strongest hub-and-spoke deployment has explainable routing, deliberate trust boundaries, workable DNS, and a tested recovery model. Its success is measured by the ability to connect authorized services safely while containing mistakes and failures. Simply counting peerings or showing a centralized firewall on the drawing tells very little about whether that goal has been achieved.
A migration program should test the effect of new spokes on existing route and policy assumptions. When a new subnet is attached to a shared application zone, a seemingly harmless route association can create traffic paths that bypass inspection or collide with a delegated team’s firewall rules. Include effective-route evidence and documented application flows in acceptance testing, not just the fact that the virtual network is peered. A reliable onboarding process refuses to promote the spoke until those boundary tests pass.