AZ-700: Connecting Azure Across Boundaries

A hybrid network is not successful merely because packets can pass between a datacenter and Azure. It must survive failures, enforce deliberate routes, preserve identity and security boundaries, and give operations teams enough visibility to diagnose problems. The AZ-700 networking exam tests this as a design and management responsibility. Its July 2026 objectives allocate 20–25% to connectivity services, including site-to-site and point-to-site VPNs, ExpressRoute and Azure Virtual WAN.

Organizations often approach hybrid connectivity as a single tunnel project. Their real requirement is usually more complicated: engineers need remote administration, applications need predictable routes to databases, branches need reliable access to cloud services, and the business needs a recovery option when a primary circuit fails. The first useful question is therefore which traffic must cross the boundary and what would happen if that path disappeared.

Map the flows before choosing the connection

Start with named applications, source networks, destinations, data sensitivity and tolerance for interruption. An internal payroll service might need to query a database in Azure; a branch office might access a customer-facing application through public endpoints rather than a private WAN. Treating both as “hybrid traffic” obscures different technical and business requirements.

A flow map should include direction and return behavior. A server in Azure may initiate a request to a datacenter system; the response must find a valid path back. Asymmetric routes through different firewalls can break otherwise valid connections, particularly where stateful inspection expects both directions. Address ranges should be checked for overlap before deciding whether a peering or tunnel configuration will work as imagined.

For critical workflows, record expected latency, throughput and recovery needs rather than defaulting to the most expensive service. The relationship between bandwidth, latency and jitter explains why capacity alone cannot define application experience. A voice workload, a nightly backup and interactive database traffic can react differently to the same nominal connection speed.

Site-to-site VPN: flexible, but design for failure

A site-to-site VPN establishes encrypted network connectivity between configured endpoints, typically over internet transport. Azure VPN Gateway uses a gateway deployed into the relevant virtual network and connections configured to represent the remote network. A local network gateway describes the remote side’s settings. The complete design also depends on on-premises equipment, address definitions and compatible encryption parameters.

Route-based VPNs are common in modern Azure designs, while policy-based approaches rely on defined traffic selectors and can impose different compatibility constraints. Tunnel establishment requires agreement on protocols and cryptographic settings; a mismatch may produce a failure even when both endpoint IP addresses are reachable. The engineer must distinguish connectivity to the tunnel endpoint from successful encrypted transport of application traffic.

High availability cannot be assumed just because a gateway has a managed service label. Evaluate gateway SKU capabilities, active-active designs when appropriate, redundant on-premises devices, diverse connections and tested recovery behavior. A failover exercise should prove that the business application’s traffic resumes, not merely that a management console reports one tunnel up. A practical understanding of VPN headend architecture helps separate tunnel termination from the routing and policy controls behind it.

Point-to-site VPN connects people, not whole branches

Point-to-site VPN supports individual clients that need private network access. That is a different problem from connecting two entire site networks. The choice of tunnel type and authentication method affects client support, user experience, control and operations. Azure designs may use supported client protocols and identity integrations such as Microsoft Entra ID or certificate-based methods, depending on the configuration.

The security question is not simply whether a remote employee can connect. What networks become accessible after connection? Does the remote device meet endpoint management requirements? How is access revoked when someone leaves the organization? A reliable design avoids using VPN connectivity as a substitute for application authorization. Network reachability alone should not imply entitlement to administrative resources.

Client troubleshooting also differs from gateway troubleshooting. A user may fail to authenticate while the gateway remains healthy. Another user may connect successfully but be unable to resolve private names or reach a subnet because of route or DNS configuration. Recording the exact phase of failure—client setup, authentication, tunnel establishment, name resolution or application access—avoids wasteful changes to working components.

ExpressRoute is a connectivity model, not a security guarantee

Azure ExpressRoute provides private connectivity through a connectivity provider rather than sending the main path over the public internet. It is often chosen for particular reliability, network architecture or performance needs. Yet private transport does not automatically encrypt application data or remove the need for segmentation and authentication. The security controls on either side remain necessary.

The design includes circuits, service-provider connectivity models, gateways and peering configuration. Azure private peering and Microsoft peering serve different traffic purposes, and candidates should understand when one or both are appropriate. The architecture must also determine how on-premises routes are advertised and how Azure prefixes are learned. A connection with the correct physical components can still behave badly if route advertisements are wrong.

ExpressRoute has specialized options. ExpressRoute Direct serves scenarios needing directly provisioned connectivity; Global Reach can connect certain on-premises networks through compatible ExpressRoute circuits; FastPath can improve the data path by changing how supported traffic is forwarded. None of these names should be treated as a blanket cure for every connectivity problem. Each has configuration, eligibility and topology constraints that should be verified against the current service guidance.

BGP makes routing dynamic—and decisions consequential

Border Gateway Protocol is central to many hybrid designs because it exchanges network reachability information instead of relying solely on static routes. This enables adaptation when paths change, but it also means an incorrect advertisement can have effects beyond the component where it originated. The engineer needs to understand which prefixes are announced, who is authorized to announce them and how routing preferences shape the effective path.

For example, a branch router might accidentally advertise an overly broad prefix that attracts traffic intended for a different network. A tunnel can remain healthy while applications fail because packets follow the wrong route. In diagnosis, ask which system knows the destination prefix, which path it selects and whether the return path agrees. The principles covered in BGP route exchange help explain why a control-plane error can resemble a transport outage.

Route filters, summarization and documented prefix ownership can limit accidental propagation. Where two routes provide redundancy, failover preference should be intentional and exercised under realistic conditions. The dashboard showing two healthy connections is less useful than evidence that the critical application uses the intended primary path and recovers when it becomes unavailable.

Design redundancy across regions and failure domains

A connection resilient to one device failure may still depend on one datacenter, one provider or one region. True resilience requires identifying independent failure domains. This may mean redundant ExpressRoute circuits, alternate VPN connectivity, geographically separated gateways or a recovery design that uses a secondary Azure region. The right choice depends on recovery objectives, cost and operational complexity.

Cross-region requirements involve more than routing a packet into a second region. Identity dependencies, DNS resolution, application state, data replication and allowed return paths must all work after failover. An application deployed in two regions can still be effectively single-region if its only private connection terminates at an unavailable gateway. Exercise plans should therefore include the complete transaction, not only the network link.

Recovery procedures also need explicit trigger conditions. Will routing shift automatically, or will an operator decide? Is failback planned, or can an early restoration create two active write paths? A sound design documents both failure and recovery behavior. It acknowledges that a technically possible fallback may be operationally impractical if the organization has never rehearsed the steps.

Virtual WAN changes how large environments are organized

Azure Virtual WAN provides an architecture for connecting sites, users and virtual networks through managed virtual hubs and related services. It can simplify large multi-branch estates, but it introduces a distinct routing model. An organization must choose the relevant Virtual WAN tier and services, size its gateway resources and decide how traffic should travel between connected networks and through security controls.

The design choice is not a contest between “modern” Virtual WAN and “old” hub-and-spoke. A small enterprise with a few VNets may prefer a conventional hub topology because it is easier to understand and control. A global enterprise with many sites and complex connectivity may benefit from a managed WAN architecture. The decision should reflect routing needs, operational skills, governance and whether centrally managed security is required.

Third-party network virtual appliances may also participate in cloud connectivity. When integrating them with a virtual hub, document who controls route exchange, where traffic inspection occurs and which team is responsible when a packet disappears. A managed hub does not relieve the organization of understanding the effective end-to-end path.

Troubleshoot by separating the layers

A hybrid incident can originate in underlay transport, tunnel establishment, route exchange, DNS, security policy or the application itself. Change control should require evidence pointing to the failing layer. For a VPN, inspect both endpoint reachability and tunnel status. For ExpressRoute, inspect circuit and peering health as well as advertised routes. For a private application, confirm which address the client resolves and whether the return path uses the expected gateway.

A seemingly intermittent application failure may correlate with route convergence or a particular branch provider, not with a broken server. A service that works from Azure but not from on-premises may lack private DNS forwarding rather than network reachability. Troubleshooting improves when tests use a documented source, destination, protocol and time, and when results can be compared from both sides of the connection.

In AZ-700 questions, resist picking a service solely because it advertises high bandwidth or global reach. Look for the actual constraint: client versus site connectivity, public versus private transport, routing control, latency, compliance, redundancy and operational model. A successful hybrid design is the one whose path, trust boundaries and failure behavior can be explained and verified under realistic business conditions.