Skip to main content

Technical Lab: Troubleshoot Network Connectivity

Questions​

Question 1 — Multiple Choice​

An operations team reports that a virtual machine cannot reach an external endpoint on the internet. The VM is in a subnet associated with a Route Table with the following configuration:

Destination prefixNext hop
0.0.0.0/0VirtualAppliance
10.0.0.0/8VnetLocal

The IP address configured as next hop for the 0.0.0.0/0 route belongs to an NVA (Network Virtual Appliance) that was deallocated two days ago.

What is the root cause of the problem?

A) The subnet does not have an associated Network Security Group, blocking outbound traffic by default.

B) The default route points to an NVA that is not responding, dropping traffic before it reaches the VNet gateway.

C) The absence of an explicit route for 0.0.0.0/0 with next hop Internet prevents any outbound traffic.

D) Azure automatically blocks outbound internet traffic when an NVA is deallocated and the route is not removed.

Question 2 — Technical Scenario​

An administrator needs to diagnose why a VM cannot communicate with another VM in the same VNet, in a different subnet. He runs the following command:

az network watcher check-connectivity \
  --source-resource /subscriptions/.../virtualMachines/vm-origem \
  --dest-address 10.1.2.4 \
  --dest-port 443

The result returns Unreachable with issues indicating NetworkSecurityRule. The administrator examines the NSG associated with the destination subnet and does not find any explicit deny rule for port 443.

What is the most likely cause of the blocking?

A) Network Watcher cannot inspect traffic between subnets in the same VNet, making the result invalid.

B) There is an explicit deny rule on the destination VM's NIC that takes precedence over the subnet rules.

C) The default DenyAllInbound rule is being applied because no allow rule for port 443 exists in the NSG, either from the subnet or the destination VM's NIC.

D) Traffic is being blocked by the source subnet's NSG, which does not have an explicit outbound rule for port 443.

Question 3 — True or False​

An administrator enables VNet Peering between two VNets in the same region. After the peering is established with Connected status on both sides, VMs in the two VNets still cannot communicate with each other. It is true to state that peering by itself guarantees effective connectivity between VMs, as long as no NSG is applied to the involved subnets.

Question 4 — Multiple Choice​

An administrator uses IP Flow Verify from Network Watcher to test if traffic on port 22 (SSH) is allowed toward a VM. The result indicates Allow. However, the SSH connection made directly from the terminal still fails with timeout.

What is the most accurate explanation for this discrepancy?

A) IP Flow Verify analyzes only NSG rules; other factors such as the SSH service state on the VM, operating system firewall, or an invalid route may be blocking the connection.

B) IP Flow Verify presents inconsistent results when the VM has been running for more than 72 hours without reboot.

C) The Allow result from IP Flow Verify indicates that traffic was allowed at some point, but does not reflect the current state of NSG rules.

D) IP Flow Verify considers only subnet NSGs; since the NIC NSG was not evaluated, it may be blocking traffic.

Question 5 — Technical Scenario​

An application hosted on a VM in the app-subnet subnet needs to access Azure Storage via Service Endpoint. The administrator enabled the Service Endpoint for Microsoft.Storage on the subnet and created the firewall rule in the Storage Account pointing to the correct VNet. Even so, the VM still receives an access denied error when trying to connect to Storage.

# Error observed on the VM:
curl: (7) Failed to connect to mystorageaccount.blob.core.windows.net: Connection refused

After reviewing the configurations, the administrator notices the following:

  • Service Endpoint enabled on: app-subnet
  • VNet rule in Storage Account points to: db-subnet

What is the appropriate correction?

A) Disable and re-enable the Service Endpoint on app-subnet to force propagation of the service route.

B) Add a static route in the Route Table of app-subnet pointing to the Azure Storage address prefix.

C) Update the VNet rule in the Storage Account firewall to reference app-subnet instead of db-subnet.

D) Enable the Service Endpoint also on db-subnet, as Azure requires both subnets to have the active endpoint for access to work.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

When a Route Table defines a route with next hop type VirtualAppliance, Azure forwards traffic to the specified IP. If the NVA is deallocated, the next hop IP stops responding, and packets are silently dropped. Azure does not automatically remove or invalidate routes whose destination becomes unreachable.

Alternative C represents a common misconception: the absence of an explicit Internet route is not the problem, because the 0.0.0.0/0 route exists and is active. The problem is where it points. Alternative D is false: Azure does not automatically block traffic based on the state of an NVA referenced in a route.

Answer Key — Question 2​

Answer: C

NSGs have implicit default rules that do not appear listed as explicit rules in the portal or CLI. The DenyAllInbound rule with priority 65500 denies all inbound traffic that was not explicitly allowed by lower priority rules. If no Allow rule for port 443 exists in the destination subnet NSG or the destination VM's NIC NSG, this default rule is applied.

Alternative B represents a real diagnostic error: it is possible that an NSG exists on the NIC, but the question states that no explicit deny rule was found, which does not rule out the absence of permission. Alternative A is incorrect because Network Watcher and check-connectivity work fully between subnets in the same VNet.

Answer Key — Question 3​

Answer: False

VNet Peering with Connected status establishes the routing plane between VNets, but does not guarantee effective connectivity by itself. Even without NSGs on subnets, other factors can block traffic: operating system firewall on VMs, absence of service listening on the destination port, or more specific routes that divert traffic. Additionally, peering needs to be Connected on both sides for traffic to flow. The statement is technically incorrect by using "guarantees" without considering the complete connectivity stack.

Answer Key — Question 4​

Answer: A

IP Flow Verify exclusively evaluates NSG rules applied to the VM (both subnet and NIC). It does not check the state of the VM's internal network stack, operating system firewall (such as iptables or ufw on Linux, or Windows Firewall), nor the validity of return routes. An Allow result means only that no NSG would block that flow. The SSH connection timeout can be caused by any of these additional factors.

Alternative D represents a relevant misconception: IP Flow Verify evaluates subnet and NIC NSGs together, not just one of the two.

Answer Key — Question 5​

Answer: C

The Service Endpoint mechanism works per subnet. The Storage Account firewall rule must reference exactly the subnet from which traffic originates. In this scenario, traffic originates from app-subnet, but the rule in the Storage Account points to db-subnet, which is a different subnet. Azure identifies the origin by the Service Endpoint of the subnet from which the packet originated, and since it is not authorized in the firewall, access is denied.

Alternative B represents a common misconception: Service Endpoints automatically inject service routes into the subnet, eliminating the need for manual static routes for service prefixes. Alternative D is false: there is no requirement that multiple subnets have the endpoint enabled for one of them to work.