Here are top Azure Network Security Policy interview questions spanning core components—including Network Security Groups (NSGs), Application Security Groups (ASGs), Azure Firewall, and Web Application Firewall (WAF)—structured by role level with key architectural takeaways.

1. Foundational & Core Security Policy Questions

Q1: What is the difference between an NSG, an ASG, and an Azure Firewall?

• Network Security Group (NSG): A basic Layer 3/4 stateful packet-filtering firewall applied at the Subnet or Network Interface (NIC) level. It evaluates rules based on source/destination IP, port, and protocol.
• Application Security Group (ASG): A logical grouping of VMs based on workload type or application role (e.g., ASG-Web, ASG-DB). ASGs are used within NSGs as source/destination abstractions so you don’t need to maintain individual static IP addresses in security rules.
• Azure Firewall: A fully managed, stateful, cloud-native Layer 3–7 firewall service. It supports threat intelligence, FQDN/URL filtering, IDPS (Intrusion Detection and Prevention System), TLS inspection, and central routing across multiple VNets.

Q2: How are NSG rules evaluated when both Subnet-level and NIC-level NSGs are applied?

• Inbound Traffic: The Subnet NSG evaluates traffic first. If allowed, the packet moves to the NIC NSG. Traffic is blocked if either NSG denies it.
• Outbound Traffic: The NIC NSG evaluates traffic first. If allowed, the packet moves to the Subnet NSG.
• Key Takeaway: Both NSGs must explicitly allow the traffic for communication to succeed.

Q3: Explain NSG Rule Priority and Default Rules.

• Priority Range: Rules are processed in order of priority from 100 to 4096 (lower numbers take higher precedence).
• Evaluation: Once a packet matches a rule’s criteria, rule processing stops (first match wins).
• Default Rules (Priority 65000+): Cannot be deleted, but can be overridden by adding higher-priority rules (e.g., < 65000):
  • AllowVNetInBound (65000)
  • AllowAzureLoadBalancerInBound (65001)
  • DenyAllInBound (65500)

2. Advanced Architecture & Deep-Dives

Q4: How does Azure Firewall Manager manage security policies across enterprise landing zones?

• Answer: Azure Firewall Manager centralizes security policy and route management across multiple Azure Firewalls and Virtual WAN Hubs.
• Firewall Policies: Hierarchical objects containing Rule Collection Groups (DNAT, Network, and Application rule collections).
• Inheritance Model: Allows a central SecOps team to enforce a Parent Policy (e.g., global threat-intel blocking and core logging) while allowing application teams to append region-specific or app-specific rules via Child Policies.

Q5: Compare Azure Firewall vs. Web Application Firewall (WAF) on Azure Front Door / Application Gateway.

• Azure Firewall: Broad L3–L7 network/application firewall designed for non-HTTP/HTTPS traffic, outbound egress filtering, and cross-subnet/cross-VNet inspection.
• Azure WAF: Specialized L7 reverse-proxy firewall designed exclusively for HTTP/HTTPS web applications. Protects against OWASP Top 10 risks (SQLi, XSS), bot attacks, and rate limiting using managed rule sets (CRS).

Q6: How do NSG Service Tags and Application Security Groups simplify rule management?

• Service Tags: System-managed aliases representing IP address prefixes for specific Azure services (e.g., Storage, Sql, AzureKeyVault). They automatically update when Microsoft adjusts backend IP ranges, removing the need to manage dynamic public IPs manually.
• ASGs: Decouple security configurations from network topology. Rather than writing rules targeting explicit static IP addresses (10.0.1.4), you write rules using ASGs (Allow ASG-Web to ASG-DB on port 1433).

3. Scenario-Based Architectural Questions

Q7: Scenario: Traffic between two subnets in the same VNet is failing, but the NSG allows port 443. How do you troubleshoot?

1. Rule Evaluation Check: Check for a higher-priority NSG rule (e.g., Priority 200 Deny vs. Priority 300 Allow) overriding the rule.
2. Effective Security Rules: Use Azure Portal or CLI (az network nic show-effective-security-rules) to inspect the combined Subnet + NIC rule evaluation on the target VM.
3. IP Flow Verify: Run Network Watcher IP Flow Verify with the specific 5-tuple payload to see which precise NSG and rule name is dropping packets.
4. Local OS Firewall: Check if the internal OS firewall (Windows Firewall / iptables / ufw) on the VM itself is blocking inbound requests on port 443.

Q8: How do you enforce asymmetric routing prevention when implementing Azure Firewall in a Hub-and-Spoke topology?

• Cause: Asymmetric routing occurs when request traffic reaches a spoke via an external route (e.g., direct public IP or Gateway), but return traffic is redirected to Azure Firewall via a 0.0.0.0/0 User Defined Route (UDR), causing the stateful firewall to drop the connection.
• Fix: Enforce SNAT (Source Network Address Translation) on Azure Firewall for internal ranges, or adjust User Defined Routes (UDRs) and Gateway Subnet routing tables so both inbound and outbound legs traverse the same firewall instance.

4. Hands-On Configuration Example: Creating an NSG with Bicep

Below is an enterprise Bicep template demonstrating an NSG configuration with rule priorities, Service Tags, and Subnet association:

param location string = resourceGroup().location
// Define Application Security Group
resource webAsg 'Microsoft.Network/applicationSecurityGroups@2023-09-01' = {
  name: 'asg-web-prod'
  location: location
}
// Define Network Security Group with Custom Rules
resource webNsg 'Microsoft.Network/networkSecurityGroups@2023-09-01' = {
  name: 'nsg-web-prod'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-HTTP-Inbound-ASG'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: 'Internet'
          sourcePortRange: '*'
          destinationApplicationSecurityGroups: [
            {
              id: webAsg.id
            }
          ]
          destinationPortRange: '443'
        }
      }
      {
        name: 'Deny-All-Inbound-Custom'
        properties: {
          priority: 4000
          direction: 'Inbound'
          access: 'Deny'
          protocol: '*'
          sourceAddressPrefix: '*'
          sourcePortRange: '*'
          destinationAddressPrefix: '*'
          destinationPortRange: '*'
        }
      }
    ]
  }
}