How do Network Security Groups evaluate inbound and outbound traffic in Azure?

Azure Network Security Groups (NSGs) provide a fundamental layer of network traffic filtering for Azure resources. They contain security rules that allow or deny inbound and outbound traffic based on attributes such as source, destination, port, protocol, and direction. Understanding how NSGs evaluate traffic is essential for Azure administrators, developers, and solution architects because an incorrectly configured rule can cause connectivity failures or unintentionally expose workloads.

For inbound traffic, Azure evaluates NSG rules before allowing traffic to reach a network interface or subnet. Rules are processed according to their priority, where a lower numerical priority is evaluated before a higher numerical priority. Once traffic matches a rule, the corresponding Allow or Deny action is applied. If no custom rule matches, Azure's default security rules determine the result.

For outbound traffic, the same principle applies, but the evaluation concerns traffic leaving the resource. NSGs can therefore control communication from workloads to databases, APIs, internet endpoints, or other networks.

NSGs can be associated with both subnets and network interfaces (NICs). This is important architecturally. A subnet-level NSG can establish broad network boundaries, while a NIC-level NSG can provide more granular protection for an individual VM. When multiple NSGs are involved, administrators need to understand how the effective security rules are determined rather than assuming that one NSG operates independently.

A common troubleshooting scenario is a virtual machine that cannot communicate with another service. Instead of immediately changing firewall settings, administrators should inspect the effective security rules, verify the source and destination addresses, confirm the protocol and port, and determine whether an NSG rule is responsible.

For example, if an application server needs TCP traffic on port 443 to an internal API, the administrator should verify the appropriate subnet/NIC rules, routing, DNS resolution, and the destination service itself. An NSG alone does not replace routing, application firewalls, or service-level authentication.

For students, the best way to learn NSGs is through hands-on labs: create two subnets, deploy test resources, deliberately block traffic, and troubleshoot the resulting connectivity problem.

For professionals, the key lesson is to design NSGs using least privilege, meaningful rule organization, and controlled administrative processes rather than broadly allowing traffic such as Any/Any.

Interview takeaway: Be prepared to explain rule priority, inbound versus outbound evaluation, subnet versus NIC association, default rules, and how you would troubleshoot an unexpected Deny.