An Azure network flow can fail despite a running server and an apparently permissive NSG. This AZ-104 guide follows the actual path through address design, VNet peering, user-defined routes, private DNS, network security rules and service authorization, using controlled fault scenarios.
A permitted connection still needs a valid route
A running VM, an open application port and an allow rule on a network security group do not guarantee that a client can connect. DNS may resolve to the wrong address, the effective route may point toward a failed network virtual appliance, or one side of a VNet peering relationship may be missing. The relevant AZ-104 skills involve configuring virtual networks and subnets, peerings, network security groups (NSGs), application security groups (ASGs), user-defined routes (UDRs), secure endpoints and Azure DNS.
VNet troubleshooting starts by distinguishing the configuration that governs packets from the evidence collected during a failed connection. Network Watcher helps inspect effective routes, security rules, connection paths and observed network behavior. Compare that evidence with peering flags, subnet associations, private endpoint DNS and the destination listener before editing an NSG or route table. If an effective next hop is wrong, changing a host firewall rule will not address the failure. Record the smallest correction and the previous known-good configuration for rollback.
Design address ranges for connectivity
Imagine a fictitious company with one shared-services hub and two application spokes. One spoke hosts a web service, while the other houses reporting systems. Pick nonoverlapping address spaces and subnets that accommodate reasonable growth. Overlapping prefixes can prevent simple peering and make hybrid routing ambiguous. Record which application services need to speak to each other and which flows must be denied.
A useful traffic matrix includes source subnet, destination hostname/IP prefix, protocol, port, business purpose, network path and authentication mechanism. A label such as "trusted network" is too broad to explain why a reporting service can read one database but not another. Start from legitimate communication needs rather than allowing every east-west connection and planning to restrict them later.
Peering does not create automatic transitive connectivity
Azure VNet peering allows connected networks to communicate using private addresses. A hub connected to two spokes does not automatically create transitive connectivity between those spokes. Peering is nontransitive. To move traffic between spokes through a hub, an architecture may require a routing service, network virtual appliance or appropriate gateway and forwarding configuration. The chosen option must match the organization’s security and operational requirements.
Peering also requires attention to each side of the relationship and to forwarded traffic. A configuration that permits the spoke to reach shared DNS does not by itself establish a route to every other spoke. Maintain an inventory of peerings, address spaces, relevant gateway transit settings and owners. A peering connection may be active while a required application path is still blocked elsewhere.
Global VNet peering supports cross-region connectivity in eligible Azure locations, but private network transport still has charges and latency. Do not use it as an argument that application-level authentication is unnecessary; identity remains independently enforced.
NSGs determine traffic admission, not network paths
Network security groups contain ordered rules matching source, destination, protocol, port and direction. The effective result can include subnet and network-interface associations plus default security rules. A higher-priority deny may defeat a lower-priority allow, even if an administrator sees an apparently correct rule in the portal.
Application security groups can identify application NICs for NSG source/destination rules where supported. They make some rule sets more maintainable than hardcoding many IP addresses, but they do not create routes or solve DNS. A group name such as "database" is only useful when group membership and rule scope actually match the deployed infrastructure.
For the fictitious web app, allow the intended inbound HTTPS path and a specific outbound database connection, while denying unrelated spoke traffic. Avoid exposing SSH or RDP to all sources simply because an operator wants quick access. Record rule priority, the source of the request and the resulting effective rules. A successful TCP handshake still does not prove the application has database permissions.
User-defined routes change the next hop
Azure installs system routes for virtual networks and connected destinations. An administrator can associate a route table with a subnet to define user-defined routes, such as sending default outbound traffic through a trusted firewall appliance. This can provide centralized inspection, but a bad next hop can blackhole traffic despite permissive NSG rules.
Azure effective routes may include system, custom and gateway-propagated routes. Route selection uses destination prefix matching and service rules, so a more-specific route can affect a flow differently from the default route. Inspect the actual network interface’s effective routing rather than looking only at the table someone intended to associate. Record the return path too; an asymmetric return through a different appliance may create a difficult diagnostic failure.
In a synthetic exercise, associate a default route with an isolated application subnet and make the next hop a simulated unavailable virtual appliance. Expect the connection to fail even though the NSG is unchanged. The right fix is to restore a reachable, approved next hop, not weaken the database’s firewall.
Private endpoints need DNS and identity
A private endpoint presents a supported Azure service through a private network interface, while a service endpoint extends supported subnet identity to the service’s public endpoint. Private Link and service endpoints therefore create different DNS, routing, firewall and resource-permission decisions. Before accepting a design, verify the current service and region’s supported network mode, the actual client DNS result and whether the intended principal can access the protected resource. A name resolving to a private address is not proof that service-level authorization or all required traffic paths passed.
A private endpoint without correct DNS integration can cause clients to resolve the ordinary public service endpoint, breaking the intended private path. Link the appropriate private DNS zone and test from every network that needs to use it, including spokes or hybrid clients where applicable. An application running in one subnet can resolve differently from an administrator’s laptop, so test from the runtime’s own resolution environment.
A private IP address is not permission to read the backing data. Validate service-level access separately with the correct identity. A 403 response from the service may mean networking is working while authorization is not.
Bastion provides a managed administrative path
Azure Bastion provides management connectivity to supported Azure VMs without routinely exposing RDP or SSH through a VM public IP. Configure its deployment and the required network path according to the current product tier and subnet requirements. It does not replace NSGs, least-privilege VM access or operating-system hardening.
In the fictitious architecture, an engineer should be able to reach an authorized VM through the approved administrative path while ordinary internet clients cannot reach its management port. The test needs both a positive allowed case and a negative denied case. A failed Bastion session should be diagnosed at the actual authentication/network control, not "fixed" by opening port 3389 worldwide.
Name resolution and routing are part of the same flow
Suppose a client cannot reach a service hostname after a private endpoint is created. It is tempting to modify NSG rules, but that may not address the destination. Resolve the name from the client, identify the IP, check selected routes and only then inspect effective security rules. If the name resolves to a stale public address, correct private DNS before changing firewall policy.
For hybrid or peered networks, verify which DNS server answers, what forwarding is configured and whether the client can reach that resolver. Name resolution is often a separate failure boundary from peering. A route to the correct destination is still useless if the application sends traffic to an unintended address.
A controlled end-to-end path test
Create synthetic hub and spoke subnets. The web-spoke VM must query a database in the data spoke through an approved hub gateway or appliance. The reporting spoke is not allowed to query that database directly. Define both expected allowed and denied paths before deployment.
Inject three independent faults. First, remove or misconfigure forwarded traffic or a necessary route between spokes. Second, insert a high-priority NSG deny that blocks the intended port. Third, point the database hostname at an unintended public address. For each case, use Network Watcher effective routes/rules and connection diagnostics to identify the right control. The successful fix must restore intended connectivity without broadening unrelated access.
Include a fourth scenario where TCP connects successfully but the service rejects the caller’s token. That case should remain a service identity issue, not a network issue. Record source NIC, DNS answer, route, security result and application response, avoiding unrestricted raw logs or secret exposure.
What this teaches for AZ-104
The important administrative reasoning is to identify the complete path: source and destination subnet, peering, DNS answer, effective route and next hop, effective NSG rule and endpoint-level identity. The correct remedy should match the failing layer. Knowing the menu locations for a VNet peering or a route table is not enough to diagnose a real outage.
Diagnose a segmented VNet incident by distinguishing configured intent from effective traffic behavior. Suppose two peered networks resolve hostnames but an application request still fails: inspect effective routes, peering and gateway flags, applied NSG rules, private-endpoint DNS and the target listener before changing production. An unrestricted NSG rule could mask the defect while exposing unrelated workloads, and a route-table edit could redirect traffic beyond the incident’s scope. An independent AZ-104 networking scenario is useful when its answer names the failed layer, the least-disruptive correction and its rollback check. The scenario is a teaching case, not a claim about an executed Azure subscription or official exam question.
Prevent network fixes from creating a broader outage
Changing a route table or NSG rule can affect many workloads beyond the one incident ticket. Before editing a production subnet, record its current associations, effective routes, expected traffic and rollback path. A policy of "allow every port temporarily" may hide the incident’s cause and expose unrelated systems. An isolated test environment is better for verifying whether a route or security rule is responsible.
Include the reverse packet path in the network acceptance case. A forward request might traverse a virtual appliance while the response chooses another route, producing asymmetric traffic that stateful network devices reject. A successful DNS lookup proves only that a name resolved; it does not prove either direction is reachable or authorized. Ask how a failover, newly peered VNet or added private endpoint changes the effective route and DNS result for each relevant client.
Write one change-approval record with source and destination, intended protocol, expected NSG match, next hop, DNS answer and affected application identity. Recheck those facts after rollout. That record is far safer than a screen capture of a single allow rule and gives a repeatable explanation if the change must be reverted.