This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Evaluate effective security rules by using Azure Network Watcher diagnostics

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Network Watcher provides diagnostic tools that help security engineers determine why network traffic is allowed or denied in Azure. For the SC-500 exam, an important capability is evaluating the effective security rules applied to a virtual machine’s network interface and using diagnostic tools to identify the rule responsible for a connectivity decision.

These capabilities are especially useful when a workload cannot connect to another resource, a management connection such as SSH or RDP fails, or an application unexpectedly has access to a network destination.

Azure Network Watcher can evaluate network security group rules and, where applicable, administrative network rules configured through Azure Virtual Network Manager. It can also help distinguish a security-rule problem from a routing, application, or service-availability problem.

What Are Effective Security Rules?

An effective security rule is the combined set of security rules that actually applies to a network interface.

The effective rules can include:

• Rules from an NSG associated with the subnet.
• Rules from an NSG associated with the network interface.
• Default NSG security rules.
• Applicable administrative rules configured through Azure Virtual Network Manager.
• Both inbound and outbound rules.

The effective rules view is therefore different from looking at only one NSG in isolation. A rule configured on the subnet-level NSG may affect a virtual machine even if the network interface itself has a different NSG.

Example

A virtual machine might have:

• A subnet-level NSG allowing TCP port 443.
• A network-interface-level NSG denying TCP port 443.
• A default outbound rule allowing Internet traffic.

Looking at only the subnet-level NSG would not provide a complete picture. The effective security rules view helps you determine which rules are applied to the selected network interface.

Why Effective Security Rules Matter

Effective security rules are useful for both troubleshooting and security governance.

Troubleshooting

You can use effective security rules to investigate:

• Failed SSH or RDP connections.
• Blocked application traffic.
• Unexpected inbound exposure.
• Unexpected outbound Internet access.
• Communication failures between virtual machines.
• Connectivity problems involving Azure Bastion.
• Conflicting rules at the subnet and network-interface levels.

Security auditing

Security teams can compare the effective rules applied to network interfaces against an approved security baseline. This can help identify:

• Unintended open ports.
• Overly broad source or destination ranges.
• Unexpected administrative rules.
• Missing deny rules.
• Differences between the intended and actual security configuration.

Azure Network Watcher also allows effective security rules to be downloaded as a CSV file, which can support documentation, review, and compliance activities.

Azure Network Watcher Diagnostic Tools

Several Network Watcher capabilities work together when evaluating security rules.

1. IP Flow Verify

IP Flow Verify determines whether a specific packet is allowed or denied by the security rules applied to a virtual machine.

You specify the characteristics of the traffic, including:

• Direction: inbound or outbound.
• Protocol: TCP or UDP.
• Local IP address.
• Local port.
• Remote IP address.
• Remote port.

The tool returns:

• Whether access is allowed or denied.
• The security rule responsible for the decision.
• The NSG containing the rule, when applicable.

For example, you can test whether a source IP address is allowed to connect to a virtual machine over TCP port 3389. If the traffic is denied, IP Flow Verify can identify the rule causing the denial.

Important limitation

IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. To evaluate ICMP-related rules, use NSG diagnostics instead. IP Flow Verify also focuses on rules applied to a virtual machine’s network interface and is not the appropriate tool for testing rules applied to virtual machine scale sets.

Example scenario

A user cannot connect to a VM using RDP.

You can run IP Flow Verify with:

• Direction: Inbound.
• Protocol: TCP.
• Local IP: The VM’s private IP address.
• Local port: 3389.
• Remote IP: The user’s source IP address.
• Remote port: The client’s source port.

If the result is:

Access denied by DenyAllInBound

you know that the traffic is being blocked by the default inbound deny rule because no higher-priority rule allows the connection.

2. Effective Security Rules

The Effective security rules feature displays the aggregated inbound and outbound rules applied to a network interface.

It helps answer questions such as:

• Which NSG rules apply to this VM?
• Is the rule associated with the subnet or network interface?
• Is an administrative rule affecting the traffic?
• Which source and destination prefixes are associated with a rule?
• Is the traffic allowed by a custom rule or a default rule?

In the Azure portal, effective security rules are grouped into inbound and outbound sections. You can select an individual rule to view additional details, including associated address prefixes.

Azure portal navigation

A typical portal workflow is:

1. Open the affected virtual machine.
2. Select Networking or Network settings.
3. Select the virtual machine’s network interface.
4. Select Effective security rules.
5. Review the inbound and outbound rules.
6. Expand or select rules to inspect their details.

If the virtual machine has multiple network interfaces, select the specific interface involved in the traffic.

Azure CLI

You can retrieve effective NSG information for a network interface by using:

az network nic list-effective-nsg \
  --resource-group <resource-group> \
  --name <nic-name>

Azure PowerShell

The equivalent PowerShell command is:

Get-AzEffectiveNetworkSecurityGroup `
  -NetworkInterfaceName "<nic-name>" `
  -ResourceGroupName "<resource-group>"

These commands provide the combined view of the rules applied to the network interface, including subnet-level rules, network-interface-level rules, and default rules.

3. NSG Diagnostics

NSG diagnostics checks whether traffic is allowed or denied by the security and administrative rules applied to a virtual machine.

It is useful when you need to evaluate traffic characteristics that may not be covered by IP Flow Verify, including ICMP traffic.

NSG diagnostics can help identify:

• The rule allowing the traffic.
• The rule denying the traffic.
• Whether the decision comes from a custom rule.
• Whether the decision comes from a default rule.
• Whether the issue is related to inbound or outbound filtering.

Microsoft’s troubleshooting guidance demonstrates using NSG diagnostics to investigate a connection failure involving Azure Bastion and a virtual machine.

4. Connection Troubleshoot

Connection troubleshoot evaluates connectivity between a source and destination. It is broader than simply checking an individual NSG rule.

It can help identify:

• Whether the destination is reachable.
• Whether a security rule allows or denies the traffic.
• Whether a route exists.
• The next hop used for the traffic.
• Whether the destination VM is running or listening.
• Whether the problem is related to routing rather than security filtering.

You can test connectivity from a virtual machine to:

• Another virtual machine.
• An IP address.
• A URI.
• An FQDN.
• An on-premises destination, depending on the network configuration.

For example, if a VM cannot connect to another VM over TCP port 3389, Connection troubleshoot can show that the traffic is allowed by the NSG but that no valid route exists. This prevents you from incorrectly changing security rules when the actual problem is routing.

Azure CLI example

az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address <destination-address> \
  --protocol TCP \
  --dest-port 443

Connection troubleshoot can also be used with a destination IP address:

az network watcher test-connectivity \
  --resource-group <resource-group> \
  --source-resource <source-vm> \
  --dest-address 10.10.10.10 \
  --protocol TCP \
  --dest-port 3389

5. Next Hop

Although Next hop does not directly evaluate NSG rules, it is valuable when diagnosing connectivity problems.

Next hop determines how Azure routes traffic from a virtual machine to a specified destination. It reports information such as:

• Next-hop type.
• Next-hop IP address.
• Route table information.

Possible next-hop types include:

• Virtual network.
• Internet.
• Virtual network gateway.
• Virtual appliance.
• None.

If a security rule allows traffic but the next hop is None, the problem may be a missing route rather than an NSG denial.

How Azure Evaluates NSG Rules

Understanding NSG evaluation is essential when interpreting Network Watcher results.

Inbound traffic

For inbound traffic, Azure evaluates the rules associated with the subnet and network interface.

The effective result depends on the applicable rules and their priorities. A matching rule with a higher priority takes precedence over a matching rule with a lower priority.

Outbound traffic

Outbound traffic is evaluated against outbound rules associated with the network interface and subnet.

A VM may be able to receive traffic from a source but still be unable to initiate outbound traffic if an outbound rule denies it.

Default rules

NSGs include default rules such as:

• Allow virtual network inbound.
• Allow Azure Load Balancer inbound.
• Deny all inbound.
• Allow virtual network outbound.
• Allow Internet outbound.
• Deny all outbound.

Custom rules with priorities from 100 through 4096 are evaluated before the default rules. If no custom rule matches, a default rule may determine the result.

Example

Suppose a VM receives an inbound TCP connection on port 80:

• A custom rule allows TCP 80 from a specific source with priority 200.
• A default inbound deny rule has lower precedence.

The custom allow rule wins because it matches the traffic and is evaluated before the default deny rule.

If no custom allow rule matches, the default inbound deny rule blocks the traffic.

Effective Rules Versus Configured Rules

The distinction between configured and effective rules is a common exam concept.

When troubleshooting, do not inspect only the NSG that appears most obvious. Always inspect the effective rules for the affected network interface.

Recommended Troubleshooting Workflow

Use the following process when a VM or application cannot communicate.

Step 1: Define the exact traffic

Record:

• Source VM or source IP.
• Destination VM, IP, URI, or FQDN.
• Direction.
• Protocol.
• Destination port.
• Source port, if relevant.
• Expected result.

A vague test such as “the server cannot connect” is less useful than:

VM-A cannot connect to VM-B over TCP port 443.

Step 2: Run IP Flow Verify

Use IP Flow Verify to determine whether the packet is allowed or denied.

If the result is Access denied, record:

• The rule name.
• The NSG name.
• The direction.
• The traffic parameters.

Step 3: Review effective security rules

Inspect the effective inbound or outbound rules on the affected network interface.

Look for:

• A custom deny rule.
• A missing allow rule.
• An unexpected subnet-level rule.
• A network-interface-level rule.
• A default deny rule.
• An administrative rule.

Step 4: Check rule priority

If multiple rules could match the traffic, compare their priorities.

Remember:

• Lower numerical priority values are evaluated first.
• A rule with priority 100 is evaluated before a rule with priority 500.
• A broad deny rule with a higher priority can override a more specific allow rule with a lower priority.

Step 5: Check routing

If the security rules allow the traffic, use:

• Next hop to inspect routing.
• Connection troubleshoot to test the complete path.

Check for:

• Missing routes.
• Incorrect user-defined routes.
• An unexpected virtual appliance.
• Incorrect peering or gateway configuration.
• Asymmetric routing.
• A destination that is not running.

Step 6: Check the destination service

If the traffic is allowed and the route is correct, verify that:

• The destination VM is running.
• The application is listening on the expected port.
• The operating system firewall allows the traffic.
• The service is bound to the correct IP address.
• The destination application is healthy.

Network Watcher can identify Azure network filtering and routing issues, but it does not replace application-level troubleshooting.

Step 7: Re-test after changes

After modifying an NSG rule or route:

1. Run the same diagnostic test again.
2. Confirm that the decision changed as expected.
3. Verify that the new rule did not create unintended exposure.
4. Document the reason for the change.

Common Troubleshooting Scenarios

Scenario 1: RDP is blocked

A user cannot connect to a VM over TCP port 3389.

Possible causes include:

• No inbound allow rule for the user’s source IP.
• A higher-priority deny rule.
• The default DenyAllInBound rule.
• An NSG associated with the subnet.
• An NSG associated with the NIC.
• The VM’s operating system firewall.
• RDP not running on the VM.

Use IP Flow Verify first to determine whether Azure NSG rules are blocking the connection.

Scenario 2: Internet access is blocked

A VM cannot access an external website over TCP port 443.

Possible causes include:

• An outbound NSG deny rule.
• A missing route.
• A firewall or virtual appliance.
• DNS resolution failure.
• The destination website being unavailable.

Use IP Flow Verify for outbound filtering, then use Connection troubleshoot and Next hop to evaluate routing and reachability.

Scenario 3: Traffic is unexpectedly allowed

A VM is accessible from a source that should be blocked.

Review:

• Effective inbound rules.
• Broad source prefixes such as *.
• Rules allowing VirtualNetwork.
• Rules allowing Internet.
• Administrative rules.
• Rule priorities.
• NSGs applied at both subnet and NIC levels.

Do not assume that the absence of a custom allow rule means traffic is blocked. Default rules may allow certain traffic.

Scenario 4: Azure Bastion cannot connect to a VM

Azure Bastion requires appropriate connectivity to the target VM. A misconfigured NSG can block the connection.

Review the effective inbound rules on the target VM’s network interface and confirm that the required traffic from the Bastion subnet is allowed. NSG diagnostics can help identify the blocking rule.

Security Best Practices

Use least-privilege rules

Avoid broad rules such as:

• Any source to Any destination.
• Any protocol.
• Any port.
• Any Internet source.

Instead, restrict rules by:

• Source IP or service tag.
• Destination IP or subnet.
• Protocol.
• Destination port.
• Business requirement.

Use explicit rule names

Use descriptive names such as:

• Allow-AppSubnet-To-Database-1433
• Deny-Internet-To-Management
• Allow-BastionSubnet-To-VM-RDP

Clear names make Network Watcher results easier to interpret.

Review effective rules regularly

A subnet-level or NIC-level NSG change may alter the effective security posture of a VM. Periodically review effective rules for sensitive workloads.

Treat default rules as part of the security model

Do not review only custom rules. Default rules can determine whether traffic is allowed or denied.

Use diagnostics before changing rules

Do not immediately create a new allow rule when connectivity fails. First determine:

1. Whether the traffic is actually denied by an NSG.
2. Which rule caused the decision.
3. Whether routing or the destination service is the real problem.

Avoid unnecessary public exposure

If a management connection is required, prefer controlled access methods such as Azure Bastion, private connectivity, or restricted source ranges rather than exposing management ports broadly to the Internet.

Export and document results

Use the effective rules export capability to support:

• Security reviews.
• Change management.
• Compliance evidence.
• Troubleshooting records.
• Baseline comparisons.

Important Exam Distinctions

IP Flow Verify versus Effective Security Rules

• IP Flow Verify answers: “Is this specific packet allowed or denied, and which rule caused the result?”
• Effective security rules answers: “What combined rules are applied to this network interface?”

IP Flow Verify versus Connection Troubleshoot

• IP Flow Verify focuses on security-rule evaluation.
• Connection troubleshoot evaluates the broader connection path, including reachability and routing.

NSG diagnostics versus Next hop

• NSG diagnostics evaluates security filtering.
• Next hop evaluates routing.

Network Watcher versus the operating system firewall

Network Watcher can identify Azure-level filtering and routing problems. It does not automatically prove that the guest operating system firewall or application is configured correctly.

Configured NSG versus effective NSG

A configured NSG is only one source of rules. Effective rules represent the aggregate configuration that applies to the network interface.

Practice Exam Questions

Question 1

A security engineer must determine whether a specific TCP connection from an external IP address to a virtual machine is allowed or denied by Azure network security rules. Which Network Watcher feature should the engineer use?

A. Next hop
B. Connection troubleshoot
C. IP Flow Verify
D. Traffic Analytics

Answer: C

Explanation: IP Flow Verify evaluates a specific traffic flow using the direction, protocol, local and remote IP addresses, and local and remote ports. It returns whether access is allowed or denied and identifies the applicable security rule.

Question 2

A virtual machine has one NSG associated with its subnet and another NSG associated with its network interface. The security engineer wants to view the complete set of inbound and outbound rules applied to the VM. What should the engineer use?

A. Effective security rules
B. Azure Monitor metrics
C. Next hop
D. Connection monitor

Answer: A

Explanation: Effective security rules display the aggregated rules from the subnet-level NSG, network-interface-level NSG, default rules, and applicable administrative rules.

Question 3

A VM cannot connect to another VM over TCP port 443. IP Flow Verify reports that the traffic is allowed. Which tool should the engineer use next to determine whether the traffic is being routed correctly?

A. Azure Policy
B. Microsoft Defender for Cloud
C. NSG diagnostics
D. Next hop

Answer: D

Explanation: Next hop identifies the route and next-hop type used for traffic to a destination. If the security rules allow the traffic, the next step is to investigate routing.

Question 4

A security engineer runs IP Flow Verify for an inbound TCP connection to port 3389. The result is Access denied by DenyAllInBound. What does this indicate?

A. The VM is powered off.
B. No higher-priority rule allowed the inbound traffic.
C. The destination route is missing.
D. The operating system firewall blocked the connection.

Answer: B

Explanation: DenyAllInBound is a default inbound NSG rule. The result indicates that no applicable custom allow rule matched the traffic before the default deny rule was reached.

Question 5

Which traffic type cannot be tested by IP Flow Verify?

A. ICMP
B. TCP
C. UDP
D. TCP over IPv4

Answer: A

Explanation: IP Flow Verify tests TCP and UDP traffic. It does not test ICMP traffic. NSG diagnostics can be used when ICMP rule evaluation is required.

Question 6

A VM’s effective security rules show that outbound traffic is allowed, but Connection troubleshoot reports that the destination is unreachable and the next-hop type is None. What is the most likely issue?

A. A higher-priority outbound NSG deny rule
B. An invalid DNS record only
C. A missing or incorrect route
D. A missing inbound NSG rule on the destination

Answer: C

Explanation: A next-hop type of None indicates that Azure does not have a valid route to the destination. The issue is routing rather than the outbound NSG decision.

Question 7

A security engineer wants to identify whether an NSG rule associated with the subnet or the network interface is blocking access to a VM. Which approach is most appropriate?

A. Review only the subnet-level NSG.
B. Review only the NIC-level NSG.
C. Review the VM’s public IP configuration.
D. Run IP Flow Verify and inspect the effective security rules.

Answer: D

Explanation: The effective rules view combines the rules applied from both the subnet and network interface. IP Flow Verify can then identify the rule responsible for a specific traffic decision.

Question 8

Which statement correctly describes Azure Network Watcher Connection troubleshoot?

A. It only lists the NSGs associated with a VM.
B. It tests connectivity and can provide information about filtering and routing.
C. It automatically changes a denied NSG rule to allow traffic.
D. It replaces the guest operating system firewall.

Answer: B

Explanation: Connection troubleshoot evaluates the broader connection path. It can identify reachability problems, security-rule decisions, and routing issues, but it does not replace the guest firewall or automatically correct configuration.

Question 9

A custom inbound NSG rule allows TCP port 22 from a trusted administrator IP address with priority 200. Another custom rule denies all inbound TCP traffic with priority 100. What is the result for an SSH connection from the trusted IP address?

A. The allow rule wins because it is more specific.
B. Both rules are evaluated and traffic is allowed.
C. The deny rule wins because it has the higher evaluation priority.
D. The default inbound rule determines the result.

Answer: C

Explanation: Lower numerical priority values are evaluated first. The deny rule with priority 100 is evaluated before the allow rule with priority 200 and therefore blocks the connection.

Question 10

A VM can connect to a destination according to IP Flow Verify, but the application still fails to communicate. Which action should be performed next?

A. Use Connection troubleshoot and verify the route, destination service, and application listener.
B. Delete all NSGs from the VM.
C. Add an allow rule for all Internet traffic.
D. Disable the VM’s operating system firewall permanently.

Answer: A

Explanation: If IP Flow Verify allows the traffic, the problem may involve routing, service availability, the application listener, DNS, or the operating system firewall. Connection troubleshoot and destination-side checks are more appropriate than broadly weakening security controls.

Summary

For the SC-500 exam, remember the following:

• Effective security rules show the combined rules applied to a network interface.
• Rules can come from subnet-level NSGs, NIC-level NSGs, default rules, and applicable administrative rules.
• IP Flow Verify evaluates a specific TCP or UDP flow and identifies the rule allowing or denying it.
• NSG diagnostics can evaluate security rules and is useful for scenarios such as ICMP traffic.
• Connection troubleshoot evaluates the broader connection path.
• Next hop helps identify routing problems.
• A denied connection is not always caused by an NSG; routing, the operating system firewall, and the destination application must also be considered.
• Lower numerical NSG priorities are evaluated first.
• Always inspect effective rules rather than reviewing only one NSG in isolation.
• Use diagnostics before modifying security rules to avoid unnecessary or overly broad access.

Go to the SC-500 Exam Prep Hub main page