AZ-500 Secure networking Practice Question

You are troubleshooting connectivity between two Azure VMs in the same virtual network. VM1 can ping VM2, but VM1's application cannot connect to VM2's application on port 8080. Both VMs have NSGs that allow inbound traffic on port 8080. What is the most likely cause?

⚠ Common exam trap

A common mix-up: candidates assume NSG rules are the only firewall layer in Azure, overlooking the guest OS firewall which operates independently and can block application traffic even when NSGs permit it.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The guest OS firewall on VM2 is blocking inbound port 8080.

Since ICMP (ping) succeeds between the VMs, the network path is functional at Layer 3, and the NSGs are allowing traffic (as stated). The application failure on a specific port (8080) while ICMP works strongly indicates a host-level firewall blocking the TCP connection. The guest OS firewall (e.g., Windows Firewall or iptables) on VM2 is the most likely cause because it operates independently of Azure NSGs and can filter traffic by port and protocol, even when NSGs permit it.

Answer analysis

Option-by-option breakdown

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

✗
The VNet is peered with another VNet that has a conflicting address space.
Why it's wrong here
VNet peering address space conflicts are irrelevant here because VM1 and VM2 reside within the same VNet. Azure VNet peering is a connection between separate VNets, and any overlapping address space would only prevent peering or affect cross-VNet routing; it does not alter the built-in system routes that deliver intra-VNet traffic between two subnets in the same VNet. Thus, a conflicting peered address space cannot explain a failure to reach VM2 on port 8080.
✗
An Azure Load Balancer is directing traffic away from VM2.
Why it's wrong here
An Azure Load Balancer operates at Layer 4 and only handles traffic destined for its own frontend IP address and port configuration. Direct traffic from VM1 to VM2's private IP address does not traverse the load balancer, because the load balancer is not inserted into the data path for VM-to-VM communications within a VNet. Even if VM2 is in the backend pool, the load balancer only influences traffic that is explicitly sent to its frontend, so it cannot 'direct traffic away' from VM2 in this scenario.
✗
The NSG on VM2's subnet has a deny rule for port 8080.
Why it's wrong here
The scenario explicitly states that the NSG on VM2's subnet allows port 8080 inbound. NSGs are stateful packet filters that evaluate traffic at the subnet or NIC level, and if there were a deny rule for port 8080, it would block the connection before it ever reached the guest OS. Since no such deny rule exists (or the existing allow rule applies), the NSG is not the cause of the connectivity failure.
✓
The guest OS firewall on VM2 is blocking inbound port 8080.
Why this is correct
The guest OS firewall on VM2 is a host-based firewall that filters traffic after the NSG has already permitted it and after the packet arrives at the virtual NIC. Even when network security groups explicitly allow port 8080, the OS firewall can still drop or reject the connection if there is no matching inbound allow rule or if an active deny rule is present. This is a common cause of 'connection refused' or timeout when all Azure network-level controls appear correct, making it the correct answer.

Visual reference

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question