AZ-500 Secure networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Route all traffic through Azure Firewall and enable logs.

  Why it's wrong here

  Forcing all traffic through Azure Firewall adds a network hop for every inter-VNet communication, introducing noticeable latency and egress processing costs while creating a potential choke point. Although firewall logs record accepted and denied connections at the application/network layer, they do not provide the granular per-interface flow metadata (source IP, destination IP, port, protocol, flow state) that NSG flow logs capture. This approach is also operationally heavy because you must redesign routing (UDRs) and fail over all traffic paths merely to obtain logging, whereas NSG flow logs work passively on existing NSGs without altering traffic flow.

• ✓

  Enable NSG flow logs and use Network Watcher traffic analytics.

  Why this is correct

  NSG flow logs capture IP-level traffic metadata (source and destination IP, port, protocol, and flow decisions like allowed/denied) for all flows passing through a network security group, with minimal performance overhead because they operate asynchronously in the Azure backbone. Network Watcher traffic analytics then ingests these logs into a Log Analytics workspace, applying machine learning and graph algorithms to surface inter-VNet communication patterns, top talkers, anomalous traffic, and cross-subnet dependencies. Together they deliver continuous, near-real-time flow visibility across multiple peered VNets without forcing traffic through a central appliance or requiring agent installation on each VM.

• ✗

  Use Network Watcher packet capture on the VMs.

  Why it's wrong here

  Network Watcher packet capture installs an extension on individual VMs and captures raw packets at the NIC level, generating substantial data volumes and consuming VM CPU/network resources. It is designed for short-term, on-demand diagnostics (e.g., inspecting a protocol handshake or troubleshooting an active issue), not for continuous monitoring of all inter-VNet traffic, because you would need to manually start/stop captures on every VM and manage large .pcap files. Additionally, packet capture sees only traffic to/from the specific VM, so it cannot provide an aggregate view of north-south or east-west flows across the entire peered topology.

• ✗

  Enable Azure Monitor metrics on the VNet peering.

  Why it's wrong here

  Azure Monitor metrics for VNet peering expose aggregate counters such as bytes transferred and packet counts in/out across the peering connection, but they do not include the source IP, destination IP, port, protocol, or flow state that are essential for security and traffic analysis. These metrics are sampled at fixed intervals and summarize total traffic volume, so they cannot tell you which workloads are communicating, whether a flow was allowed or denied, or how a specific attack might be traversing your peered VNets. Thus they are useful for capacity planning but insufficient for detecting malicious flows, aligning with security requirements, or auditing per-connection activity.

Go deeper

Related to this question