A virtual network is not secure just because its resources have private IP addresses. The routes may send traffic to unexpected destinations, management ports may be publicly exposed, and a platform service may still be reached through its public endpoint. AZ-104 administrators must understand route tables, service endpoints, Azure Bastion and related connectivity controls without treating them as interchangeable.
Imagine a VM in a spoke VNet reaching a storage account and a central inspection appliance. Traffic must follow an intended path, respect security rules and use a suitable administrative-access model. The difference between ‘traffic has a route’ and ‘traffic is authorized and reachable’ determines whether this architecture will work.
Read effective routes before adding UDRs
Azure creates system routes for VNet prefixes, internet destinations and other platform behavior. User-defined routes (UDRs) allow administrators to override some next-hop choices for specific prefixes. The effective routes seen by a NIC reflect the combined routing environment. A route table associated with the wrong subnet may have no effect on the VM actually failing connectivity.
For a packet destined for a 10.40.0.0/16 network, determine the most specific applicable route and next-hop type. Don’t assume that adding a broad default route forces every Azure platform-service connection through an appliance; service and platform-routing behavior must be verified for the chosen endpoint. Record the source subnet, destination IP, route prefix and next hop before changing a production route table.
Effective routes show the combined result of Azure system routes, user-defined routes and propagated gateway routes for a network interface. For a workload that unexpectedly sends traffic to a firewall, identify the destination prefix, longest matching route and selected next hop before changing anything. An apparently harmless 0.0.0.0/0 UDR can redirect all internet-bound traffic from a subnet; a more specific route may still win for one private destination. Compare the route output on the actual source NIC, not a different machine in the same VNet with a different subnet association. Routing problems should be solved as packet paths, not by guessing which route-table name looks relevant.
Control forced tunneling and appliance return paths
A next-hop virtual appliance can be useful for inspection, but both forward and return paths matter. If a spoke VNet sends traffic to a firewall and the returning traffic bypasses it, stateful inspection may break the session. IP forwarding and appliance capabilities also need to match the routing design. A UDR by itself does not make a VM into a functioning router.
Consider an API tier in a spoke network that loses database connectivity after a new inspection route is attached. Inspect effective routes at the API NIC and the return path from the database side. Check appliance health, expected next hop, NSG rules and peering forwarding settings separately. Removing the route may restore service but defeat the intended security boundary; identify the correct symmetric design before rollback.
Forced tunneling may satisfy inspection policy but increases dependence on a network virtual appliance and its return path. A spoke routes outbound traffic to a hub firewall, which then forwards the flow; the response must return through an allowed symmetric path if the firewall tracks state. If another route sends return traffic directly to the spoke, stateful inspection can drop packets even when both NSGs allow the ports. Document source, destination, next hops in both directions and any NAT applied. Test NVA failover and scale capacity rather than assuming Azure peering provides an automatic redundant transit device.
Bastion is a management-access path, not general transit
Azure Bastion provides a managed way to connect to supported VMs for administrative sessions without requiring those VMs to expose public management ports in the conventional way. It addresses how an operator reaches a guest for troubleshooting. It is not a substitute for general application network routing, a site-to-site VPN or a public load balancer.
For a production VM that needs occasional RDP, review whether the Bastion deployment, subnet and connectivity are in place. Authenticate the administrator appropriately, control who may initiate sessions and log activity under the organization’s policy. Do not keep a wide-open port 3389 or 22 rule simply because it helps during the first installation. The operational requirement is accessible management with controlled exposure.
Azure Bastion establishes a managed administrative connection to supported VMs without requiring those guests to expose a public RDP/SSH endpoint. It is not a generic next hop for application data or a replacement for VPN connectivity. For a production access design, consider which users may launch Bastion sessions, whether private network access is required, how session activity is governed and what VM guest credentials or Entra-based access is supported. An operator unable to open an RDP session might be missing Azure rights, Bastion permissions, guest login rights or a permitted path. Opening TCP 3389 to the world masks the distinction and introduces a new attack surface.
Service endpoints have a different boundary from private endpoints
Virtual-network service endpoints extend VNet identity to supported Azure services while the service continues to use its public service endpoint model. A private endpoint introduces a private IP-based interface in the VNet for a particular supported service. The two approaches have different DNS, reachability, cost and security implications. Selecting one because the other is mentioned in a nearby portal blade can produce a subtly wrong architecture.
For a storage account restricted to a trusted VNet subnet, a service endpoint may meet the service and network policy if its limitations fit. Where the requirement is private-IP access to a specific resource, a private endpoint may be more suitable. In either case, storage authorization still applies; networking does not automatically grant a principal permission to read blobs.
A service endpoint extends VNet identity to supported Azure services while clients still generally use the service’s public service endpoint address. A private endpoint maps a supported service connection onto a private IP inside a VNet and depends on correct private DNS. These are different network constructs. When a storage-account firewall should allow one subnet, a service endpoint may be relevant if its threat model and supported service match. When the requirement says the account should not be reachable through its public interface, investigate Private Link and public-network-access restrictions instead. Confirm service and region limitations before treating the options as interchangeable.
DNS often reveals the hidden wrong path
A private endpoint can be configured correctly while a client still resolves the service hostname to a public destination because its DNS zone is missing, not linked, or not reachable from its resolver. Conversely, a service endpoint configuration does not require the same private DNS mapping behavior. Troubleshoot a client by retrieving the actual resolved address and comparing it with the intended network architecture.
An on-premises workstation attached through a VPN may use a different DNS server from a VM inside Azure. If only remote users fail, compare resolver paths before changing the service’s public access setting. Expanding a storage firewall to ‘allow all networks’ can make a broken private-DNS configuration appear fixed while weakening the environment’s controls.
Use Network Watcher to validate the packet path
Network Watcher offers tools such as next hop, effective routes, IP flow verify and connection troubleshooting for supported resources. Choose the tool for the layer being investigated: effective routes show the routing table, next hop helps explain forwarding to a destination, and flow verification focuses on NSG filtering. A successful next-hop check does not confirm application authentication.
Record the intended destination IP, the observed address and the source interface. If the route points at an appliance, verify appliance forwarding and policy. If the NSG denies traffic, change only the necessary rule. If DNS provides an unexpected destination, repair name resolution. The diagnostic sequence should explain the packet’s experience, not merely produce green screenshots.
The most useful Network Watcher checks are specific. Next hop answers how Azure expects to route a packet to a destination. IP flow verify checks whether a defined flow is permitted by applicable NSG policy. Connection troubleshoot tests actual end-to-end connectivity from an eligible source. A network failure can pass one tool and fail the next because each interrogates a different layer. Save the result with source interface, destination, time and expected service port. When an app owner requests a new allow-all rule, a focused diagnostic record helps prove whether the existing network is actually responsible.
Protect administrative changes during outages
Route-table edits can interrupt production access to the very VM needed for recovery. Before applying a UDR, identify who can change it, how they can connect if it blocks traffic and what rollback route is safe. Keep emergency management access separate from application traffic where reasonable. A remote administrator should not have to depend entirely on the faulty route being repaired to reach a console.
Use controlled incremental rollout: test in a disposable subnet with representative dependencies, compare route tables, then apply to a narrow production scope and monitor connectivity. Record a precise reverse change. Even small-looking changes to a default route can have a very large blast radius, so the review should describe affected prefixes and subnets explicitly.
Solve a multi-layer AZ-104 network scenario
Construct a hub-and-spoke lab with an application VM in the spoke, a second endpoint in another subnet and a mock storage dependency. Verify the system routes, associate a narrow custom route and observe effective next hops. Where available, connect through Bastion rather than opening a public RDP or SSH port. Compare a service endpoint with private-endpoint DNS behavior in a supported configuration.
Introduce a wrong DNS answer or an incorrect appliance next hop and record which evidence proves the fault. The exercise teaches the administrator to select routing, management access and platform-service connectivity mechanisms based on requirements—not to use one feature as a cure for every network outage.
Consider an administrator whose VM can resolve a storage account but can’t download a blob. The subnet has a default UDR to an appliance, a service endpoint for Storage and an NSG permitting outbound HTTPS. First check which IP the hostname resolves to and which route wins; then test the exact TCP connection and confirm Azure Storage data permissions. If policy requires private connectivity, a service endpoint might not satisfy it, and private endpoint DNS may need a separate design. Resolve the case by identifying the layer at fault. An NSG rule change would be inappropriate if the server is reachable but returns an authorization denial.