Skip to main content
  1. Home
  2. >
  3. Azure
  4. >
  5. AZ-104
  6. >
  7. This article

Azure AZ-104 Drill: Network Performance Monitoring - The Latency Detective Solution

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | Multi-Cloud Architect & Strategist.
Jeff's Architecture Insights
Go beyond static exam dumps. Jeff’s Insights is engineered to cultivate the mindset of a Production-Ready Architect. We move past ‘correct answers’ to dissect the strategic trade-offs and multi-cloud patterns required to balance reliability, security, and TCO in mission-critical environments.

While preparing for the AZ-104 (Microsoft Azure Administrator), many candidates struggle with selecting the appropriate Azure Network Watcher feature for specific diagnostic scenarios. In the enterprise world, this decision often hinges on understanding the difference between real-time troubleshooting vs. continuous monitoring. Let’s drill into a simulated cross-VNet performance issue.

The Scenario
#

Fabrikam Manufacturing operates a distributed application architecture spanning two Azure virtual networks. VNet-Frontend (located in East US) hosts VM-WebApp01, which runs their customer-facing inventory management portal. VNet-Backend (located in Central US) hosts VM-DataAPI02, which provides real-time product availability data through REST APIs.

The networks are connected via VNet peering with BGP route propagation enabled. Recently, customer support has received multiple reports that the inventory portal is experiencing intermittent slowness during peak hours (9 AM - 11 AM EST). Initial Azure Monitor metrics show CPU and memory utilization within normal ranges on both VMs.

The IT operations team suspects network latency between the frontend and backend tiers. They need to establish a baseline measurement of average packet round-trip time (RTT) between VM-WebApp01 and VM-DataAPI02 to determine if cross-region latency is contributing to the performance degradation.

Key Requirements
#

Identify the Azure Network Watcher feature that provides continuous monitoring of average packet round-trip time (RTT) between two virtual machines in different virtual networks.

The Options
#

  • A) IP Flow Verify
  • B) Connection Troubleshoot
  • C) Connection Monitor
  • D) NSG Flow Logs

Correct Answer
#

C) Connection Monitor


The Architect’s Analysis
#

Correct Answer
#

Option C: Connection Monitor

Step-by-Step Winning Logic
#

Connection Monitor is purpose-built for continuous, automated monitoring of connectivity and latency metrics between Azure resources. It operates by:

  1. Deploying lightweight agents (Network Watcher extension) on source VMs
  2. Executing periodic connectivity checks (configurable intervals: 30s to 30 min)
  3. Collecting performance metrics including RTT, packet loss percentage, and reachability
  4. Storing historical data in Log Analytics for trend analysis and alerting

This aligns with the Performance Efficiency pillar of the Well-Architected Framework by enabling:

  • Proactive detection of degradation patterns before user impact
  • Baseline establishment for SLA validation
  • Integration with Azure Monitor Alerts for automated incident response

For Fabrikam’s scenario, Connection Monitor would reveal whether the 9-11 AM slowness correlates with increased RTT (suggesting network congestion) or remains stable (pointing to application-layer bottlenecks).

The Trap (Distractor Analysis)
#

  • Why not A (IP Flow Verify)?

    • IP Flow Verify is a point-in-time diagnostic tool that validates whether a packet would be allowed or denied by NSG/ASG rules. It answers “Can traffic reach the destination?” not “How long does it take?” It provides no latency metrics and operates on a single test execution model, not continuous monitoring.
  • Why not B (Connection Troubleshoot)?

    • Connection Troubleshoot performs on-demand connectivity tests with single-run diagnostics. While it does report RTT for that specific test, it’s designed for reactive troubleshooting (“Why can’t I connect right now?”) rather than establishing performance baselines over time. You’d need to manually execute tests during each incident window.
  • Why not D (NSG Flow Logs)?

    • NSG Flow Logs capture traffic flow metadata (source/destination IPs, ports, protocol, allow/deny decisions) for security auditing and traffic pattern analysis. They contain no latency or performance data—only connection attempts and their outcomes. They’re a governance/compliance tool, not a performance monitoring solution.

The Architect Blueprint
#

graph TB subgraph VNet-Frontend [VNet-Frontend - East US] VM1[VM-WebApp01<br/>Network Watcher Agent] end subgraph VNet-Backend [VNet-Backend - Central US] VM2[VM-DataAPI02<br/>Target Endpoint] end subgraph Monitoring Infrastructure CM[Connection Monitor<br/>Test Configuration] LA[Log Analytics Workspace] Alert[Azure Monitor Alert<br/>RTT > 100ms] end VM1 -.->|Periodic Probes<br/>Every 60s| VM2 VM1 -->|RTT Metrics<br/>Packet Loss %| CM CM -->|Store Time-Series Data| LA LA -->|Threshold Breach| Alert Alert -.->|Notify| Admin[Operations Team] style VM1 fill:#0078D4,stroke:#333,color:#fff style CM fill:#5C2D91,stroke:#333,color:#fff style LA fill:#FF8C00,stroke:#333,color:#fff style Alert fill:#D13438,stroke:#333,color:#fff

Diagram Note: Connection Monitor deploys an agent on the source VM to execute periodic connectivity tests, storing RTT and reachability data in Log Analytics for alerting and historical analysis.

The Decision Matrix
#

Option Capability Use Case Data Retention Integration with Alerts Estimated Effort
A. IP Flow Verify NSG rule validation “Is traffic blocked?” N/A (single test) None Low (Portal click)
B. Connection Troubleshoot On-demand connectivity test “Why can’t I connect now?” Not stored Manual only Low (Portal test)
C. Connection Monitor Continuous latency/reachability monitoring “What’s my baseline RTT?” 30-90 days (LA retention) Full Azure Monitor support Medium (agent + workspace)
D. NSG Flow Logs Traffic flow auditing “Who accessed what?” 7-365 days (storage tier) Via Log Analytics queries Medium (storage + Traffic Analytics)

Cost Consideration:

  • Connection Monitor: $1.50 per test/month (standard frequency) + Log Analytics ingestion ($2.30/GB)
  • NSG Flow Logs: Storage costs only ($0.03/GB S3) + optional Traffic Analytics ($0.50/GB processed)
  • For Fabrikam’s two-endpoint scenario: ~$5-10/month for Connection Monitor vs. $0 for on-demand tools (but no historical data).

Real-World Practitioner Insight
#

Exam Rule
#

“For the AZ-104 exam, always pick Connection Monitor when you see keywords like ‘continuous monitoring,’ ‘average RTT,’ ‘baseline performance,’ or ‘historical latency data.’ Pick Connection Troubleshoot for ‘immediate diagnostic’ or ‘one-time test.’

Real World
#

In production environments, we typically deploy Connection Monitor during the initial stabilization phase (first 30 days post-migration) to establish performance baselines, then transition to Azure Monitor Metrics for VMs (which includes network-in/out bytes) for ongoing monitoring. Connection Monitor becomes a troubleshooting tool reactivated when Application Insights detects dependency latency spikes.

Hybrid Complexity: For hybrid scenarios with Azure Arc-enabled servers on-premises, Connection Monitor can test connectivity between Azure VMs and on-premises workloads, making it invaluable for validating ExpressRoute or VPN Gateway performance. However, the on-premises machine must have the Network Watcher extension deployed via Azure Arc agent—this isn’t automatic and requires careful RBAC configuration.

CAF Alignment: The Manage methodology in the Cloud Adoption Framework emphasizes “baseline operational telemetry.” Connection Monitor fulfills this by providing the L4 (transport layer) visibility required to distinguish between network issues vs. application bottlenecks—a critical capability for operations teams transitioning from on-premises NetFlow tools.

Weekly Azure AZ-104 Drills

Master Azure administration from identity to networking.