Technical Lab: Verify IP flow
Questionsβ
Question 1 β Multiple Choiceβ
An engineer needs to determine if a VM can send TCP traffic on port 443 to an external IP address. He uses the IP flow verify feature in Azure Network Watcher and gets the result Access: Deny.
What additional information does IP flow verify provide that allows the engineer to start diagnosis immediately?
- A) The name of the NSG rule that blocked the traffic, identifying exactly which rule and in which NSG it is defined.
- B) The complete path of the packet through the network topology, including all NSGs and User Defined Routes traversed.
- C) The automatic suggestion of which rule should be modified to allow the traffic.
- D) The log of the blocked packet with timestamp, source and destination MAC address.
Question 2 β Technical Scenarioβ
An administrator runs the following verification in Azure Network Watcher to diagnose a connectivity issue:
Direction: Inbound
Protocol: TCP
Source IP: 203.0.113.45
Source Port: 54321
Destination IP: 10.0.1.10
Destination Port: 80
VM: vm-webserver (NIC: nic-webserver)
The returned result is Access: Allow. However, the administrator still cannot access the web application on the VM from the internet. What is the most accurate conclusion about what the IP flow verify result indicates and what it doesn't cover?
- A) The result confirms that the NSG associated with the NIC allows the traffic; the problem may be in the subnet NSG, which IP flow verify doesn't evaluate separately.
- B) The result confirms that there is no network blocking between the internet and the VM; the problem is necessarily at the application layer.
- C) The result indicates that at least one of the evaluated NSGs allows traffic for that specific flow; the problem may be in another component not covered by the verification, such as the application state or an internal VM firewall.
- D) The result is invalid because the source IP used is an RFC 5737 documentation address and IP flow verify rejects reserved IPs.
Question 3 β Multiple Choiceβ
When configuring IP flow verify, the engineer must choose the direction of traffic to be tested. Considering that the goal is to verify if a VM can initiate an outbound connection to an external database server on port 1433, which combination of parameters correctly represents this scenario?
- A) Direction: Inbound; Source IP: Database IP; Destination Port: 1433; Destination IP: VM IP.
- B) Direction: Outbound; Source IP: VM IP; Destination Port: 1433; Destination IP: Database IP.
- C) Direction: Outbound; Source IP: Database IP; Destination Port: 1433; Destination IP: VM IP.
- D) Direction: Inbound; Source IP: VM IP; Destination Port: 1433; Destination IP: Database IP.
Question 4 β True or Falseβ
IP flow verify evaluates NSG rules from both the subnet and the NIC associated with the VM in a single verification, returning the combined result of the most restrictive policy between the two NSGs.
Question 5 β Technical Scenarioβ
A team receives a complaint that a specific VM stopped responding to pings from another VM in the same VNet. The administrator runs IP flow verify with the following parameters:
Direction: Inbound
Protocol: ICMP
Source IP: 10.0.2.5
Source Port: *
Destination IP: 10.0.1.20
Destination Port: *
VM: vm-target (NIC: nic-target)
The result is Access: Allow. The administrator concludes that the NSG is not the problem and ends the network investigation. What is the error made in this decision?
- A) IP flow verify doesn't support the ICMP protocol; therefore, the
Allowresult is a false positive and NSG investigation should continue. - B) The
Allowresult only confirms the NSG rules evaluation for that specific flow; the administrator should also verify if ICMP isn't blocked by an operating system firewall within the VM, which is outside the scope of IP flow verify. - C) The administrator inverted the source and destination IPs; IP flow verify for inbound traffic should have the VM IP as source, and the obtained result doesn't reflect the real scenario.
- D) The
Allowresult only indicates that the defaultAllowVNetInBoundrule is active; custom blocking rules with higher priority are not evaluated by IP flow verify.
Answer Key and Explanationsβ
Answer Key β Question 1β
Answer: A
IP flow verify was designed to return not only the verdict (Allow or Deny), but also the NSG rule name responsible for the decision and the NSG name where it is defined. This is what differentiates the feature from a simple connectivity test: it maps the decision directly to an auditable rule.
Alternatives B and D describe capabilities of other Network Watcher tools. Complete topology tracing is the function of Connection Troubleshoot or Network Topology. Logs with timestamp and MAC address are generated by NSG Flow Logs. Alternative C is never a behavior of an Azure diagnostic tool: automatic rule correction suggestions are not part of IP flow verify.
Answer Key β Question 2β
Answer: C
IP flow verify evaluates NSG rules associated with the VM's NIC and subnet for the specified flow. An Allow result means that none of the evaluated NSGs blocked that flow. This doesn't guarantee end-to-end connectivity because the feature doesn't cover: operating system firewalls, state of the process listening on the port, Azure Firewall, routes that might divert traffic, or application layer failures.
Alternative A is wrong because IP flow verify evaluates both NSGs (NIC and subnet) together, not just the NIC's. Alternative B goes beyond what the result proves. Alternative D is wrong: IP flow verify accepts any valid IP address as a test parameter, including IPs from the documentation block.
Answer Key β Question 3β
Answer: B
To verify if a VM initiates an outbound connection, the correct direction is Outbound. In this case, the VM is the traffic source, so its IP should be the Source IP. The destination server receives traffic on the service port, which for SQL Server is 1433, being the Destination IP.
Alternative A inverts the direction and the source and destination roles. Alternative C uses Outbound correctly but inverts the IPs, which would produce an evaluation of outbound rules considering the VM as destination, which doesn't make sense. Alternative D uses Inbound, which would evaluate VM inbound rules, not outbound. Confusing the direction perspective is the most common error in this type of configuration.
Answer Key β Question 4β
Answer: False
IP flow verify doesn't return a combined result between the subnet NSG and the NIC NSG. It evaluates both NSGs and returns which specific rule made the decision, identifying in which NSG it is. This means that if the subnet NSG blocks traffic, the result will indicate the blocking rule in that NSG; if the NIC NSG blocks, it will indicate the rule in the NIC NSG.
The statement is false mainly in the phrase "combined result of the most restrictive policy": there is no rule fusion. The two NSGs are evaluated in sequence (subnet first for inbound traffic, NIC first for outbound), and the first matching rule in either one determines the verdict. IP flow verify exposes which rule won and where it is, which is exactly the diagnostic value of the feature.
Answer Key β Question 5β
Answer: B
IP flow verify limits its evaluation to the control plane of NSGs associated with the VM. An Allow result confirms that no NSG rule is blocking the ICMP flow to that VM. However, ICMP may be being dropped by Windows Firewall or by iptables within the VM's operating system, which are layers completely independent from NSG and outside the scope of Network Watcher.
Alternative A is wrong: IP flow verify supports ICMP as a test protocol. Alternative C describes a misconception about the parameters: for inbound traffic, the source IP is who sends (the ping source VM, 10.0.2.5) and the destination IP is the VM that receives, which is correctly configured in the scenario. Alternative D is wrong because IP flow verify evaluates all NSG rules in priority order, not just default rules; the highest priority rule that matches the flow is what determines the result.