A logistics company keeps its warehouse systems on-premises while moving customer analytics and internal applications to Azure. Its initial site-to-site VPN carries the traffic reliably during testing, but shipment reporting slows when overnight data exports compete with production requests. A dedicated connection seems like the answer. The network team discovers that hybrid connectivity involves more than replacing one link: address planning, routing, DNS, security policy, redundancy, cost, and operating ownership all determine whether the cloud and campus can function as one dependable environment.
The Microsoft AZ-700 exam expects candidates to design and implement hybrid connectivity as part of Azure networking, not merely recognize product names. A strong solution starts with the requirements of individual workloads and the failure behavior the organization can tolerate. Private circuits, encrypted tunnels, and managed routing services can all play roles, but no single choice automatically provides application continuity.
Choose connections from traffic requirements
Site-to-site VPN uses encrypted tunnels over internet connectivity and can be a practical starting point for many workloads. Azure ExpressRoute provides private connectivity through an approved connectivity provider, with different performance, routing, and service-level considerations. ExpressRoute is not a synonym for end-to-end encryption; security requirements may still require encryption on the data path. Compare solutions using throughput, latency predictability, route scale, reliability objectives, provider coverage, lead time, and cost.
Start by classifying data flows. A batch transfer can run outside peak hours; a voice service may be sensitive to latency and jitter; a payment system may need strict continuity and audit evidence. One physical design may carry several flow classes, but they might need different prioritization and recovery arrangements. Without such classification, bandwidth estimates often reflect the easiest test rather than the production workload.
Hybrid connectivity also has organizational dependencies. Provisioning a circuit may involve telecom contracts, cross-connects, firewall teams, security approvals, and change windows. A technically sound ExpressRoute design can fail a launch date if the physical access arrangement takes longer than expected. Project planning should distinguish service configuration from provider delivery and customer-premises readiness.
Understand gateways and virtual network architecture
Azure VPN Gateway terminates supported VPN connections and participates in routing for connected networks. ExpressRoute gateways enable connectivity between virtual networks and ExpressRoute circuits under the applicable architectural model. Gateway SKUs, performance limits, availability options, and route capabilities should be selected from current service guidance and tested for the required traffic volume. A small pilot gateway may become inadequate when large production workloads arrive.
Hub-and-spoke architectures often centralize hybrid gateway access to avoid individually connecting every spoke. Gateway transit and associated peering settings must be planned. Virtual network peering alone does not automatically turn a hub into unrestricted transit between all destinations. Engineers should trace how a packet leaves a spoke, reaches the chosen gateway or inspection point, and returns to the correct source.
If multiple sites or branches are involved, Azure Virtual WAN may help consolidate connectivity and routing operations. Its value depends on scale and desired central management; introducing it for two simple networks can add complexity. Compare options in terms of ongoing route administration, security inspection, and failure domains rather than focusing solely on the ease of initial deployment.
Plan addressing and BGP deliberately
Hybrid networking exposes address mistakes that isolated cloud projects can ignore. Overlapping on-premises and Azure CIDR ranges make normal routing ambiguous. If an acquired company uses the same private network as an existing Azure spoke, engineers may face renumbering, translation, or architectural restructuring. Reserve sufficient nonoverlapping address space and record allocation decisions across both environments.
BGP can exchange route information between supported gateways and customer networks. It helps automate reachability updates, but it also introduces the need to understand advertised prefixes, route preference, session status, and convergence behavior. A BGP session can remain healthy while a more specific route directs traffic to a path that violates security policy. Review effective routes and test expected failover from both sides.
Route symmetry matters when stateful firewalls or inspection devices are present. Azure may send traffic over a different return path from the one chosen on-premises if route policies differ. This can create intermittent application problems that resemble software defects. Document primary and alternate paths in both directions, including traffic that uses virtual appliances or changes as a result of propagation.
Design DNS across the boundary
Moving a service does not automatically move its hostname. On-premises applications may need to resolve Azure private endpoints, while cloud workloads still depend on internal corporate domains. Establish authoritative zones, conditional forwarding, name resolution paths, and resilience requirements before a large migration. DNS decisions can be more difficult to change later than network routes because hostnames become embedded in certificates, configuration, and operational runbooks.
Azure DNS Private Resolver and other supported DNS arrangements can help bridge name resolution without maintaining ad hoc forwarding servers everywhere. Their configuration requires deliberate inbound and outbound query paths, network security rules, and availability planning. An application that reaches a private database address during testing but resolves its hostname publicly after migration may appear to suffer a routing failure when the root cause is incorrect DNS.
Test the actual client locations: branch offices, corporate data centers, Azure spokes, and any disaster-recovery site. Caching and split-horizon behavior can cause two clients to receive different responses for the same name. Operators should capture the queried resolver, resulting record, and request path when troubleshooting rather than assuming that name resolution is globally consistent.
Secure hybrid paths and privilege boundaries
A private or encrypted network connection is not evidence that all attached systems should trust one another. Segment sensitive subnets, control application ports, and restrict access to administrative endpoints. NSGs, firewalls, and other policy points should reflect specific traffic needs. A compromised desktop network should not gain unrestricted access to production cloud databases merely because ExpressRoute makes the packets routable.
Identity and application authorization must remain independent from network access. Users should not receive broader data permissions simply because they are on corporate premises. Cloud service identities, managed identities, and Microsoft Entra policies help express which principals may act on resources. The Microsoft cybersecurity architecture context reinforces that network location is one signal among many, not a substitute for verified identity and least privilege.
Operational access also needs contingency planning. If the normal corporate network is unavailable, incident responders may need a narrowly authorized recovery path to inspect Azure services. That path must be secure, monitored, and tested. A break-glass mechanism that has not been exercised often fails precisely when the team needs it most.
Test resilience beyond a single circuit
Redundancy requires independence. Two VPN tunnels through one internet circuit do not protect against a site-wide provider failure. Two dedicated connections whose customer side shares a critical router can still fail together. Consider redundant locations, devices, providers, and gateways according to workload criticality. No infrastructure diagram should promise an availability outcome without testing the actual recovery path.
A network failover can restore reachability while existing applications fail to reconnect or data transfers resume incorrectly. Test customer-visible transactions, session recovery, and backlog processing. Measure recovery time against business targets and assess whether backup capacity can carry real peak traffic. A secondary link sized only for occasional administrative access cannot support all production workflows during a major failure.
Monitoring should detect loss of redundancy before the main application fails. VPN tunnel state, BGP health, gateway metrics, route changes, and end-to-end latency deserve appropriate alerts. During an incident, responders must identify whether the problem is on-premises, with a provider, in Azure routing, or within the application. A shared incident timeline reduces argument between teams and speeds recovery.
Operate connectivity as an evolving service
Document ownership of circuits, gateways, network appliances, DNS zones, route advertisements, and escalation contacts. Provider contacts and support procedures should be available even when the primary corporate network is down. Use regular change reviews for prefix expansions, new spokes, or security policies that could affect many connected sites. A route modification made for a test environment should not silently alter production traffic.
Capacity and architecture should be revisited as applications migrate. Network usage may shift from data-center-to-cloud traffic toward cloud-to-cloud traffic, making yesterday’s expensive central path unnecessary for some flows. Conversely, a newly introduced regulated workload may require additional redundancy or monitoring. Hybrid design is a living operating model, not a one-time networking project.
The best preparation for AZ-700 hybrid questions is to examine the full chain from client to application and back. Choose connectivity based on service objectives, model addresses and routes, resolve names correctly, enforce security independently, and prove failover under realistic conditions. The resulting network should be understandable to operators and resilient in the ways that matter to the business.
An enterprise should also evaluate the implications of connection ownership during a provider failure. Azure engineers may control gateways and route tables while a carrier controls the circuit and the premises team controls edge routers. If operational responsibility is split without shared incident procedures, each group may observe its own equipment as healthy while users remain disconnected. Agree on what evidence each team can supply, the escalation sequence, and whether temporary traffic changes are preapproved. Recovery depends as much on this coordination as on redundant hardware.
During maintenance, avoid relying on a single quiet pilot transaction to prove the route works. Exercise long-lived connections, large data transfers, authentication, and service-to-service calls. Compare telemetry before and after the path switch to detect unintended latency or bandwidth degradation. The test should also show that the original primary route can be restored without routing loops or asymmetric inspection failures. Those details are what turn a design statement about resilience into an operational capability.