Troubleshooting practice questions

A security administrator is troubleshooting network connectivity to an Azure virtual machine. The VM is behind a network security group (NSG) that has a deny-all inbound rule as the default. The administrator wants to quickly verify whether a specific TCP packet on port 3389 from their client IP (203.0.113.50) would be allowed or blocked by the NSG. Which Azure Network Watcher tool should they use?

Trap 1: Network Performance Monitor.

Network Performance Monitor is used to measure latency, packet loss, and performance across networks, not for rule validation.

Trap 2: Next hop.

Next hop identifies the next hop type and IP address for a packet based on routing, but it does not evaluate NSG rules. It is used for route table diagnosis.

Trap 3: NSG diagnostics (flow logs).

NSG flow logs are used to capture and log all traffic flows for analytics, not for real-time validation of a specific simulated packet.

A
Network Performance Monitor.
Why wrong: Network Performance Monitor is used to measure latency, packet loss, and performance across networks, not for rule validation.
B
IP flow verify.
This tool simulates a packet and evaluates NSG rules to determine if the traffic is allowed or denied. It provides immediate feedback for troubleshooting NSG issues.
C
Next hop.
Why wrong: Next hop identifies the next hop type and IP address for a packet based on routing, but it does not evaluate NSG rules. It is used for route table diagnosis.
D
NSG diagnostics (flow logs).
Why wrong: NSG flow logs are used to capture and log all traffic flows for analytics, not for real-time validation of a specific simulated packet.

Question 2mediummultiple choice

You are troubleshooting a sign-in issue. A user reports that they are repeatedly prompted for authentication when accessing a cloud app, even though they already authenticated earlier in the day. You check the Conditional Access policy and see that 'Session control - Sign-in frequency' is set to 1 hour. What is the most likely cause?

Trap 1: The browser is blocking persistent cookies

Persistent cookies affect session persistence, not sign-in frequency.

Trap 2: Token lifetime policy overrides the sign-in frequency

Token lifetime policies set maximum token validity but do not override sign-in frequency.

Trap 3: The user is considered high risk by Identity Protection

Risk-based policies are not indicated.

A
The sign-in frequency setting forces reauthentication after 1 hour
Sign-in frequency requires reauthentication after the specified time.
B
The browser is blocking persistent cookies
Why wrong: Persistent cookies affect session persistence, not sign-in frequency.
C
Token lifetime policy overrides the sign-in frequency
Why wrong: Token lifetime policies set maximum token validity but do not override sign-in frequency.
D
The user is considered high risk by Identity Protection
Why wrong: Risk-based policies are not indicated.

Read the full NAT/PAT explanation →

Question 3hardmultiple choice

You are troubleshooting an Azure virtual machine that cannot access the internet. The VM is in a subnet with a route table that has a default route (0.0.0.0/0) with next hop 'Virtual appliance' pointing to the private IP of an Azure Firewall. The Azure Firewall has a DNAT rule to allow outbound traffic. You verify that the VM's NSG allows outbound traffic. What is the most likely cause of the issue?

Trap 1: Azure Firewall does not support SNAT for outbound traffic.

Azure Firewall supports SNAT for outbound traffic.

Trap 2: The route table does not have a default route.

The route table has a default route pointing to the firewall.

Trap 3: The VM's NSG is blocking outbound traffic.

The scenario states NSG allows outbound traffic.

A
Azure Firewall does not support SNAT for outbound traffic.
Why wrong: Azure Firewall supports SNAT for outbound traffic.
B
The route table does not have a default route.
Why wrong: The route table has a default route pointing to the firewall.
C
The VM's NSG is blocking outbound traffic.
Why wrong: The scenario states NSG allows outbound traffic.
D
The Azure Firewall does not have an allow rule for outbound internet traffic.
Azure Firewall denies all traffic by default; an allow rule must be configured for outbound internet.

Question 4hardmultiple choice

You are troubleshooting connectivity between two Azure virtual machines in different VNets that are peered. VM1 (10.0.1.4) cannot reach VM2 (10.0.2.4) on port 80. Both VNets have NSGs allowing HTTP traffic from each other's IP ranges. The VNet peering is in 'Connected' state. You verify that the VMs' operating system firewalls allow HTTP. What is the most likely cause of the connectivity issue?

Trap 1: NSGs are not stateful and require explicit outbound rules.

NSGs are stateful; outbound return traffic is automatically allowed.

Trap 2: The VNet peering status is disconnected.

The peering is in 'Connected' state, so it is working.

Trap 3: Azure Firewall is blocking traffic between the VNets.

No Azure Firewall is mentioned in the scenario.

A
NSGs are not stateful and require explicit outbound rules.
Why wrong: NSGs are stateful; outbound return traffic is automatically allowed.
B
The VNet peering status is disconnected.
Why wrong: The peering is in 'Connected' state, so it is working.
C
Azure Firewall is blocking traffic between the VNets.
Why wrong: No Azure Firewall is mentioned in the scenario.
D
The NSG on VM2's subnet does not allow inbound traffic from VM1's VNet address space.
NSGs filter traffic even across peered VNets; you must allow the source IP range.

Read the full VPN explanation →

Question 5hardmultiple choice

You are troubleshooting connectivity from an on-premises network to an Azure VM. The connection uses a site-to-site VPN. The VM can be pinged from on-premises, but an application running on the VM cannot connect to an on-premises database server. The database server's firewall is configured to allow connections from the Azure VPN gateway public IP. What is the most likely cause of the issue?

Trap 1: An NSG on the VM's subnet is blocking outbound traffic.

NSGs do not block traffic to on-premises; they block inbound/outbound within Azure.

Trap 2: The VPN tunnel is not established.

If ping works, the tunnel is up.

Trap 3: The effective routes on the VM are misconfigured.

Ping works, so routing is likely correct.

A
An NSG on the VM's subnet is blocking outbound traffic.
Why wrong: NSGs do not block traffic to on-premises; they block inbound/outbound within Azure.
B
The VPN tunnel is not established.
Why wrong: If ping works, the tunnel is up.
C
The effective routes on the VM are misconfigured.
Why wrong: Ping works, so routing is likely correct.
D
The on-premises firewall is allowing the wrong IP address. The Azure VPN gateway's private IP should be allowed.
Azure VPN gateway uses its private IP for traffic to on-premises, not the public IP.

Read the full DNS explanation →

Question 6hardmultiple choice

You are troubleshooting connectivity issues from an Azure VM to an on-premises server. The VM is in a VNet that uses a custom DNS server. The on-premises network is connected via ExpressRoute. You can ping the on-premises server by IP address but not by name. What is the most likely cause?

Trap 1: The ExpressRoute circuit is not configured for DNS forwarding.

ExpressRoute does not provide DNS resolution.

Trap 2: The Azure Private DNS zone does not include the on-premises…

Private DNS zones are for custom domains in Azure, not on-premises.

Trap 3: An NSG rule is blocking DNS traffic.

DNS traffic is UDP/53, and pinging by IP works, so the issue is name resolution, not blocking.

A
The ExpressRoute circuit is not configured for DNS forwarding.
Why wrong: ExpressRoute does not provide DNS resolution.
B
The custom DNS server does not have a conditional forwarder to the on-premises DNS.
Custom DNS servers must forward queries to on-premises DNS for name resolution.
C
The Azure Private DNS zone does not include the on-premises hostname.
Why wrong: Private DNS zones are for custom domains in Azure, not on-premises.
D
An NSG rule is blocking DNS traffic.
Why wrong: DNS traffic is UDP/53, and pinging by IP works, so the issue is name resolution, not blocking.

Question 7hardmultiple choice

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?

Trap 1: The VNet is peered with another VNet that has a conflicting address…

Peering conflicts would not affect intra-VNet traffic.

Trap 2: An Azure Load Balancer is directing traffic away from VM2.

Load balancers do not affect direct VM-to-VM traffic.

Trap 3: The NSG on VM2's subnet has a deny rule for port 8080.

The NSG allows port 8080 per the scenario.

A
The VNet is peered with another VNet that has a conflicting address space.
Why wrong: Peering conflicts would not affect intra-VNet traffic.
B
An Azure Load Balancer is directing traffic away from VM2.
Why wrong: Load balancers do not affect direct VM-to-VM traffic.
C
The NSG on VM2's subnet has a deny rule for port 8080.
Why wrong: The NSG allows port 8080 per the scenario.
D
The guest OS firewall on VM2 is blocking inbound port 8080.
Guest OS firewall can block traffic even if NSGs allow.

Read the full NAT/PAT explanation →

Question 8hardmultiple choice

You have an Azure subscription with multiple VNets connected via VNet peering. You need to audit all network traffic between two specific VNets for compliance. The solution must capture traffic metadata (source/destination IP, ports, protocol) without affecting performance. What should you use?

Trap 1: Route all traffic through Azure Firewall and enable logs.

Adds latency and cost.

Trap 2: Use Network Watcher packet capture on the VMs.

Not scalable for continuous monitoring.

Trap 3: Enable Azure Monitor metrics on the VNet peering.

Metrics provide aggregate statistics, not flow data.

A
Route all traffic through Azure Firewall and enable logs.
Why wrong: Adds latency and cost.
B
Enable NSG flow logs and use Network Watcher traffic analytics.
Captures metadata with minimal performance impact.
C
Use Network Watcher packet capture on the VMs.
Why wrong: Not scalable for continuous monitoring.
D
Enable Azure Monitor metrics on the VNet peering.
Why wrong: Metrics provide aggregate statistics, not flow data.