Microsoft AZ-700: Network Monitoring & Troubleshooting — Study Guide

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Part of the Microsoft Azure Network Engineer AZ-700 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Observability tooling and data sources

Observability in Azure networking centers on Network Watcher, Azure Monitor (Log Analytics), and diagnostic settings that stream telemetry from resources into a central workspace or storage account. Network Watcher provides packet capture, IP flow verify, next hop, connection troubleshoot and Connection Monitor; Connection Monitor v2 supports multi-endpoint, multi-protocol tests and stores results in a Log Analytics workspace for queryable telemetry. NSG flow logs are enabled through Network Watcher and write JSON records to a storage account; enabling Traffic Analytics (which requires flow logs + a Log Analytics workspace) enriches those logs with application/geo insights and visualization. Diagnostic settings on Azure Firewall, Application Gateway/WAF, Front Door, and load balancers should be routed to the same Log Analytics workspace to correlate signals. Common traps include storage account firewall rules blocking flow log writes, forgetting to enable Network Watcher per region in older tenants, and inconsistent retention policies across storage vs. Log Analytics. Cost and capability trade-offs are clear: write raw logs to a storage account for low-cost archival versus ingesting into Log Analytics for query and alerting (higher cost but far greater diagnostic value). Role-Based Access Control (Monitor Reader plus Storage Blob Data Reader where required) must be configured so diagnostic pipelines can write and analysts can read logs.

Packet capture, Connection Monitor, and deep diagnostics

For packet-level troubleshooting, Network Watcher packet capture (via portal/CLI/PowerShell) creates PCAP files to a storage account or to a local VM file. Configure packet capture filters (protocol, src/dst IP, ports) and size/time limits to avoid excessive storage and performance impact. For high-throughput VMs with accelerated networking, host-side packet visibility may be limited; use VNet TAP to mirror traffic to a collector VM or NVA to avoid missing offloaded packets. Connection Monitor should be used for active synthetic tests: define source and destination endpoints (IP, FQDN, port), choose test frequency and enable per-hop latency and path capture for multi-segment diagnosis. Use IP Flow Verify to check whether a specific 5-tuple is allowed or denied by NSGs/UDRs, and Next-hop to confirm effective routing. Watch for pitfalls: packet capture on Windows VMs may require elevated permissions and can be impacted by OS offloads; packet capture can be CPU/disk intensive so prefer targeted filters and timeboxes. For continuous packet inspection at scale, pair VNet TAP with a packet analytics appliance or cloud SIEM that can ingest PCAP streams.

NSG flow logs, Traffic Analytics, and security diagnostics

NSG flow logs (version 2) provide flow records with timestamps, 5-tuple, byte/packet counts and decision (allowed/denied). They do not contain payload, application-layer session details or decrypted TLS. Traffic Analytics enriches flow logs with top talkers, ASNs and geo-mapping, requiring a Log Analytics workspace. Azure Firewall, Application Gateway/WAF, and Azure Front Door emit their own diagnostics; these must be directed to Log Analytics for unified querying. Important design traps: NSG rules applied at NIC level take precedence over subnet-level rules; default rules exist (e.g., AzureLoadBalancer, internet rules) and cannot be removed, only overridden by higher priority rules. Flow logs are only as useful as the retention and ingestion strategy—long retention in Log Analytics is expensive, while short retention risks losing forensic evidence. Combine NSG flow logs with Firewall diagnostic logs and Alert rules based on Kusto queries to detect lateral movement or data exfiltration. When planning remedial actions, consider adding dedicated public IPs to Azure Firewall to mitigate SNAT port exhaustion and leverage DiagnosticSettings to route to Event Hubs for SIEM integration if Log Analytics costs are prohibitive.

Troubleshooting patterns, routing pitfalls and design trade-offs

When troubleshooting connectivity, follow a layered approach: verify resource-level NSG/UDR, check effective routes and next hop, use IP Flow Verify and Connection Troubleshoot, then escalate to packet capture or VNet TAP if needed. Routing pitfalls often surface with forced tunneling, overlapping CIDRs, or misconfigured UDRs that send traffic into AzureFirewallSubnet without appropriate return routes. For load balancing and scale, choose between Azure Standard Load Balancer, Application Gateway WAF, and Front Door based on L4 vs L7 needs and global vs regional traffic management. Consider these SKU trade-offs:

Azure Firewall Standard vs Premium: Premium adds TLS inspection, IDPS and URL filtering at higher cost; choose Premium when deep traffic inspection and regulatory control are required.
Azure Front Door Standard vs Premium: Premium supports advanced WAF features and private link integrations; Standard is lower cost for typical global CDN + routing.
VNet TAP vs packet capture: TAP is higher cost but required for lossless capture at scale and when accelerated networking offloads packets. Trade-offs center on performance, cost, and resilience: NVAs can be cheaper or more feature-rich than Firewall Premium but add management overhead and single-point-of-failure risk unless architected with HA. Plan for SNAT capacity, reserve spare public IPs, and stage diagnostic pipelines to balance observability needs against ingestion costs.

Practical Problem: Use-Case Scenario

Scenario: Contoso Electronics operates a two-region Azure footprint (EastUS, WestEurope) with hub-and-spoke VNets, an Azure Firewall Standard in the hub, multiple spoke Application Gateway WAFs, and a central Log Analytics workspace for monitoring. They recently deployed a set of production VMs in a spoke that report intermittent failures reaching an on-premises SQL cluster via an ExpressRoute circuit.

Challenge: Intermittent connectivity and high latency to on-premises resources without clear packet-level evidence; existing NSG flow logs are enabled but show allowed flows with no latency metrics.

Recommended Approach:

Deploy Connection Monitor v2 from representative VMs to the on-premises SQL FQDN and IP using TCP port 1433, set tests every 30 seconds, and send results to the central Log Analytics workspace to capture per-hop latency and reachability.
Enable Network Watcher packet capture on an affected VM with filters for src/dst IP of the SQL cluster and port 1433, store PCAPs to a storage account with a lifecycle policy; simultaneously enable VNet TAP on the spoke subnet to mirror traffic to a dedicated collector VM if accelerated networking is present.
Configure diagnostic settings for Azure Firewall (Standard) to send application and network logs to the same Log Analytics workspace, and run correlation queries joining Connection Monitor results, firewall logs, and NSG flow logs to detect firewall SNAT exhaustion or policy drops.
Use IP Flow Verify and Next Hop for a failing 5-tuple during an incident; if SNAT or asymmetric routing is suspected, add an additional public IP to the Azure Firewall or deploy a NAT Gateway in the spoke for predictable egress and update UDRs to route through the hub.

Rationale: Connection Monitor gives synthetic, timestamped reachability and per-hop latency; packet capture and VNet TAP provide lossless forensic data when OS offloads obscure traffic. Correlating firewall and NSG logs in Log Analytics identifies policy, SNAT, or asymmetric routing issues; adding public IPs or NAT Gateway mitigates port exhaustion and stabilizes egress behavior.

← Load Balancing · All domains · Azure Virtual WAN →

Practice these questions → · Timed practice on ExamRoll.io →