A service intermittently times out, yet all its VMs show ‘Running’ in Azure. The platform health indicator tells you that compute exists; it cannot prove that TCP connections reach the intended database or that a remote office receives a usable HTTP response. The AZ-104 exam includes Azure monitoring and diagnostic tools that help administrators narrow the failure to a network path and prove when the repair is effective.
Network Watcher supplies diagnostic capabilities. Connection Monitor continuously tests chosen source–destination paths and records latency and failure behavior. Those tools complement Azure Monitor logs and metrics rather than replace application observability. Knowing when to use a one-time probe versus a continuous test is a practical operating skill.
Define the connection you need to observe
A network test is meaningful only when it describes a concrete source, destination, protocol and port. A VM can ping a destination while failing TCP 443 because intermediate rules or the application differ. An HTTP request can respond with an authentication error while the underlying network path is healthy. Define expected application behavior separately from the network probe result.
For a payroll API, identify which subnets and users require access, the actual DNS hostname, the expected port and acceptable latency. Test from a source that represents the failing consumer. Running a diagnostic from an unrelated VM can produce a reassuring success while the original office still has a blocked route.
Write a monitor specification using a real source, destination, protocol, port, probe interval and acceptable latency or failure threshold. ‘Monitor the network’ is not an actionable requirement. For example, a payroll VM in one spoke needs TCP 1433 connectivity to a SQL private endpoint in another network; a useful monitor tests that path from the actual VM rather than checking that an unrelated Azure service is online. Record the service owner and the expected response to an alert. Metrics from a synthetic test indicate connectivity, not necessarily database correctness, so pair network monitoring with service-specific application health evidence.
Use IP flow verify for a specific filtering question
IP flow verify determines whether an NSG rule would allow or deny a specified packet at a supported VM context. Specify protocol, direction, local and remote endpoints and port details. A deny result names the relevant policy decision; it does not imply the application is down. A permit result means that this particular NSG evaluation does not block the packet, not that every component on the path allows it.
If a database port stops working after a new subnet rule, simulate exactly that flow and compare it to a functioning port. Avoid making an Any-to-Any permit to silence the alert. Once the blocking rule is identified, ask whether the traffic is genuinely authorized and adjust the rule only if it is supposed to be allowed.
IP flow verify answers a particular policy question for a source or destination VM: would a specified packet be allowed or denied by the network security rules and which rule would decide? Enter the direction, local/remote IP addresses and ports that actually belong to the failed connection. A result showing Allowed does not prove the target service is listening, the DNS name resolves correctly or the user has the right data permissions. Conversely, an NSG Deny result identifies the filtering rule without requiring a risky change. Save the result with a timestamp and compare the same tuple before and after a narrow approved correction.
Check effective routes and next-hop behavior
Effective routes show forwarding decisions combining system, configured and other applicable routes. Next-hop diagnostics can help identify where Azure expects to send traffic for a particular destination. These answer different questions from NSG filtering. A correct NSG allowance cannot repair a route that points at an unavailable appliance or the wrong network prefix.
For an application calling a service in a peered VNet, examine the source interface’s effective route to the service address. If a UDR diverts traffic through a firewall, check the appliance and return route. A packet may reach its next hop and still fail later, so compare test evidence with appliance logs and destination-side observations when available.
The Next hop diagnostic identifies the route Azure expects traffic to use to reach a chosen destination. Suppose a workload can resolve its storage account but cannot connect after a route-table change. Check effective routes from its NIC and the next hop selected for the storage endpoint. If a virtual appliance is selected, verify forwarding, firewall policy, return traffic and NAT rather than removing security controls indiscriminately. Compare route selection with the actual application’s destination address, especially where a private endpoint changes DNS to a private IP. Routing is a different diagnostic from an NSG allow decision, and both may be necessary.
Choose continuous monitoring rather than repeated manual checks
Connection Monitor can test supported Azure, hybrid and external endpoints over configurations such as TCP, ICMP and HTTP. It organizes sources, destinations, test configurations and groups, then captures failure percentages and round-trip times. This is useful for a path that fails only during peak traffic: a one-time successful diagnostic at midday may miss an outage that happens every evening.
Set thresholds that reflect the application’s tolerance rather than accepting every alert by default. Different destinations may need different measures. A slow but successful HTTP connection might violate a user-facing service requirement, while a blocked ICMP packet could be intentional policy. Test behavior, monitored protocol and escalation rule must be consistent with the service contract.
Connection Monitor is suited to ongoing reachability and latency testing. It can group supported source and destination endpoints with protocol-specific tests, report the percentage of failed checks and round-trip time, and feed monitoring data to Azure Monitor and Log Analytics. The source agent and supported target choices are important. An arbitrary client laptop outside the supported monitor configuration cannot simply become a first-class probe by clicking a button. Test the service topology with realistic source workloads, then add monitoring only where it can produce an owned operational action. Microsoft has retired the classic Connection Monitor experience; avoid reproducing that old configuration in a new deployment.
Make alerts actionable with context
Connection Monitor metrics and logs can support Azure Monitor alerts when configured. A useful alert identifies source, destination, protocol, threshold and recent trend. Without those details the on-call responder may see only ‘connection unhealthy’ and spend minutes determining which business flow matters. Correlate the network observation with application failures and infrastructure changes.
For a regional deployment, separate a failure that affects one client from one that affects all clients to the same service. A sudden increase in latency from one office may indicate a local path issue; a shared failure across sources points toward a destination or common dependency. Avoid automatic broad remediation that restarts every VM when the real fault is external connectivity.
Capture point-in-time evidence during incidents
Network Watcher connection troubleshoot and packet capture can supplement continuous monitoring when supported. Choose tools with care: packet data can contain sensitive operational information, and not all tools or targets support identical diagnostics. Capture only what the incident requires, protect resulting files and limit retention according to policy.
A good incident record includes timestamps, affected regions, source and destination IPs, failed test results, relevant NSG or route decisions and application symptoms. This makes it possible to compare the same path after a change. An engineer who cannot reproduce the original failure may falsely credit the last action taken for a spontaneous recovery.
Packet capture can be useful after policy and route diagnostics narrow the problem, but capture itself can expose credentials, internal names or sensitive payloads. Set a defined duration, narrow filters and an approved storage destination; retain captures only as long as investigation requires. If a connection appears to reset, correlate both the VM’s host logs and the network observation before concluding that Azure routing dropped the traffic. VPN troubleshoot is similarly specific: it diagnoses supported VPN gateway connections, not arbitrary application authentication or DNS behavior. Choose the tool for the layer that remains unproven.
Avoid retiring tools in new configurations
Connection Monitor (classic) is deprecated, and Microsoft documents migration to the current Connection Monitor model. Separately, NSG flow logs are retiring, with Microsoft directing new and existing users toward virtual network flow logs. These transitions matter when a study guide or old portal screenshot describes a feature that should no longer be provisioned for new workloads.
When inheriting a monitoring environment, inventory which logging and connectivity-monitoring components are active and which have retirement dates. Keep required historical records according to retention policies, but update the forward-looking design. AZ-104 competence means choosing supported current operations, not reproducing every step of a legacy tutorial.
Run an evidence-based AZ-104 connectivity drill
Create a test source VM and target endpoint with a predictable response. Configure a small Connection Monitor test that measures a meaningful port and compare passing and failing results. Temporarily block the test flow with a narrow NSG rule, observe the failure and use IP flow verify to confirm why it occurred. Restore only that necessary rule.
Next, deliberately alter the route or DNS resolution in a disposable environment and show why the NSG diagnostic is no longer the correct answer. Save the before-and-after data and a brief statement of the real cause. The exercise turns Network Watcher from a set of menu items into a disciplined sequence for diagnosing Azure connectivity.
A good lab deliberately blocks one known TCP connection between two disposable VMs. First record the expected result, use IP flow verify to identify the rule, and inspect the effective route and next hop. Correct the rule at the narrowest scope and repeat the test. Next create a supported Connection Monitor test group and collect several observations before declaring success. Finally break name resolution while leaving the network rules unchanged, demonstrating that an allowed packet path and a valid application hostname are separate requirements. Cleanup removes the temporary deny, probe resources and unnecessary stored diagnostic data.