AZ-305 Hybrid Network Connectivity: VPN Gateway, ExpressRoute, Virtual WAN, Private Link, and DNS

For AZ-305 hybrid networking questions, decide the boundary first. Use VPN Gateway for encrypted site-to-site or point-to-site connectivity over the public internet. Use ExpressRoute when the scenario requires private provider-backed connectivity, predictable latency, higher bandwidth, or enterprise resiliency. Use Virtual WAN when many branches, users, regions, VPNs, and ExpressRoute circuits need Microsoft-managed hub routing. Use Private Link/private endpoints to expose a specific Azure PaaS resource through a private IP, not to replace a WAN. Use Private DNS zones and DNS Private Resolver when names must resolve correctly across Azure and on-premises.

This is current AZ-305 scope: Microsoft lists Design infrastructure solutions at 30-35%, and the study guide includes recommending connectivity to on-premises networks, network performance, network security, and routing solutions (AZ-305 exam page, AZ-305 study guide).

Compact Decision Shortcut

• Need encrypted connectivity from one site, lab, small production environment, or remote users: start with VPN Gateway (VPN Gateway overview).
• Need private connectivity that avoids the public internet and offers more predictable performance: evaluate ExpressRoute (ExpressRoute overview).
• Need many branches, SD-WAN integration, regional hubs, transitive VNet connectivity, VPN plus ExpressRoute interconnect, or Microsoft-managed hub routing: evaluate Standard Virtual WAN (Virtual WAN overview, Azure topology guidance).
• Need a private IP path to one PaaS service such as Storage, SQL, Key Vault, or App Service: use a private endpoint, then fix DNS (private endpoint overview, private endpoint DNS).
• Need hybrid name resolution for private endpoints and on-premises domains without DNS VMs: use DNS Private Resolver with inbound and outbound forwarding where it fits (DNS Private Resolver architecture, hybrid DNS architecture).

One Mental Model

The exam trap is treating these as substitutes. They are layers. VPN Gateway, ExpressRoute, and Virtual WAN move traffic between networks. Hub-spoke and Virtual WAN decide where that traffic transits and where policy is enforced. Private Link narrows access to a specific service endpoint. DNS makes the private path usable by real applications.

Decision Cards

VPN Gateway

Choose VPN Gateway when the scenario needs IPsec/IKE site-to-site connectivity, point-to-site user access, VNet-to-VNet encrypted tunnels, or a lower-cost hybrid path that can tolerate internet variability. Microsoft describes VPN Gateway as encrypted traffic between Azure VNets and on-premises locations over the public internet, with site-to-site, point-to-site, and VNet-to-VNet options (VPN Gateway overview).

Boundary: VPN Gateway is not the same as ExpressRoute. If the requirement says private circuit, predictable latency, high bandwidth, or mission-critical dedicated connectivity, compare ExpressRoute. If the requirement says many branches and global transit, compare Virtual WAN.

ExpressRoute

Choose ExpressRoute when the design needs private connectivity through a provider, consistent latency, higher throughput, BGP route exchange, and stronger enterprise resiliency. Microsoft says ExpressRoute extends on-premises networks into Microsoft cloud over a private connection and does not send traffic over the public internet (ExpressRoute overview).

Boundary: ExpressRoute does not remove the need for routing design. A VNet still needs an ExpressRoute gateway or a Virtual WAN hub connection, and spoke VNets usually use the centralized gateway rather than deploying their own. Microsoft also recommends additional resiliency planning for critical workloads, such as using more than one circuit or peering location.

Virtual WAN

Choose Virtual WAN when the architecture is becoming a network-of-networks: many branches, remote users, SD-WAN devices, multiple Azure regions, site-to-site VPN, point-to-site VPN, ExpressRoute, and VNet-to-VNet transit. Microsoft describes Virtual WAN as a Microsoft-managed networking service with hubs, branch connectivity, ExpressRoute, user VPN, site-to-site VPN, inter-hub transit, Azure Firewall, and NVA support in Standard Virtual WAN (Virtual WAN overview).

Boundary: Basic Virtual WAN is site-to-site VPN only. Standard Virtual WAN is the exam-relevant answer when the scenario says ExpressRoute, user VPN, inter-hub transit, VNet-to-VNet transit, or secured virtual hub routing. Also remember that a VNet can connect to only one virtual hub.

Hub-Spoke

Choose traditional hub-spoke when a platform team wants direct control over routing, firewalls, NVAs, gateway placement, and workload isolation. Microsoft's hub-spoke reference architecture places shared services in a hub and connects spokes through peering; the hub can host VPN Gateway or ExpressRoute for cross-premises connectivity (hub-spoke topology).

Boundary: VNet peering is nontransitive, so do not assume every spoke automatically talks to every other spoke. Use gateway transit for centralized on-premises connectivity, direct peering or Virtual Network Manager for selected spoke-to-spoke paths, or a hub NVA/firewall when traffic must be inspected.

Private Link and Private Endpoints

Choose Private Link when the target is a specific Azure service or customer/partner service that should be reached through a private IP in a VNet. Microsoft says a private endpoint is a network interface with a private IP address that connects privately to a service powered by Azure Private Link (private endpoint overview).

Boundary: Private Link is not a branch connectivity service. It does not connect the whole datacenter to Azure. It changes how clients reach a specific resource, and the DNS path must resolve the normal service FQDN to the private endpoint IP.

Private DNS and DNS Private Resolver

Choose Private DNS zones for private endpoint records and private Azure names that VNets need to resolve. Choose DNS Private Resolver when Azure and on-premises DNS must forward to each other without running DNS forwarder VMs. Microsoft's hybrid DNS architecture uses inbound endpoints for on-premises-to-Azure resolution and outbound endpoints plus rulesets for Azure-to-on-premises forwarding (DNS Private Resolver architecture, hybrid DNS architecture).

Boundary: DNS is often the hidden failure. Microsoft warns that private endpoint DNS must be configured correctly, and private endpoint zone design can cause resolution issues if multiple endpoints for the same service are handled incorrectly.

Worked Scenario: Three Branches, One Datacenter, and Private SQL

A company has one datacenter, three small branches, two Azure regions, and a payment application in a spoke VNet. The app must reach Azure SQL privately. Admins work remotely. The company expects ten more branches next year.

First pass: use VPN Gateway if this is only the datacenter plus a few branches and the latency requirement is ordinary. If the payment app needs predictable private connectivity from the datacenter, use ExpressRoute for that path and keep VPN as backup or for sites not on ExpressRoute. If the ten new branches will use SD-WAN and need branch-to-branch, branch-to-Azure, user VPN, and multi-region transit, move the design toward Standard Virtual WAN instead of hand-building every route and peering.

For the Azure side, put shared connectivity in a hub or Virtual WAN hub. Put application tiers in spokes. Use Private Link for Azure SQL, but do not stop there: link the correct private DNS zone to the VNets that need resolution, and configure DNS Private Resolver if on-premises clients must resolve the private endpoint FQDN.

Exam-ready answer: choose the connectivity service for the network scale, choose hub-spoke or Virtual WAN for the transit model, choose Private Link for the SQL service boundary, and choose private DNS plus resolver rules so names follow the private path.

What Wrong Answers Reveal

• Choosing ExpressRoute for one small lab means you may be over-weighting "private" and under-weighting cost and operational complexity.
• Choosing VPN Gateway for a high-bandwidth mission-critical datacenter path means you missed the private circuit and predictable performance clues.
• Choosing traditional hub-spoke for dozens of branches across regions means you may be ignoring Microsoft-managed transit and SD-WAN integration.
• Choosing Private Link to connect a branch office means you confused service-level private access with WAN connectivity.
• Forgetting DNS means you understand the network diagram but not the application path.
• Assuming peering is transitive means you missed a core hub-spoke boundary.

For CramHQ practice, label each miss with one decision lens: transport, transit, service boundary, DNS, or routing control. That is a better remediation target than rereading every networking page.

How to Study This Without Memorizing a Matrix

Practice scenario rewrites. Change one requirement at a time:

• Replace "small branch" with "50 branches using SD-WAN." Does Virtual WAN become stronger?
• Add "traffic must not traverse the public internet." Does ExpressRoute become stronger?
• Add "remote developers need laptop access." Does point-to-site VPN matter?
• Add "Storage must be reachable only through a private IP." Does Private Link become the service boundary?
• Add "on-premises apps must resolve the private endpoint name." Does DNS Private Resolver enter the design?

That drill matches AZ-305 because the correct answer changes when the architecture boundary changes.

If the scenario shifts from connectivity to workload placement, review the AZ-305 compute hosting guide. If it shifts from private access to data placement, use the AZ-305 data storage guide as the next decision drill.

Where CramHQ Fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help turn wrong networking answers into a focused learning loop: identify whether the miss came from transport selection, transit topology, private endpoint scope, DNS resolution, or route-control assumptions, then use targeted remediation, lessons, practice, and readiness planning across the AZ-305 path.

When you are ready, take the AZ-305 assessment. After each missed networking question, write one sentence: "I picked the wrong connectivity design because I missed ____." Fix that boundary, then retest nearby scenarios.

Quick Recap

Use VPN Gateway for encrypted internet-based VPN connectivity, ExpressRoute for private provider-backed connectivity, Virtual WAN for Microsoft-managed large-scale transit, hub-spoke for customer-managed routing and shared services, Private Link for private access to a specific service, and private DNS/DNS Private Resolver so hybrid clients resolve the right private addresses. On AZ-305, the best answer is usually the one that separates transport, topology, service exposure, and name resolution instead of treating "private network" as one feature.