Question

Difficulty: HardConfigure Network Security Groups (NSGs) and Application Security Groups (ASGs)

An enterprise deploys a virtual network named `VNet-Prod` containing two subnets: `Subnet-App` (172.16.1.0/24172.16.1.0/24) and `Subnet-Data` (172.16.2.0/24172.16.2.0/24). A virtual machine named `VM-Web` resides in `Subnet-App`, and its network interface `NIC-Web` is associated with an Application Security Group named `ASG-Web` and a Network Security Group named `NSG-NIC-Web`. Another virtual machine named `VM-DB` resides in `Subnet-Data`, and its network interface `NIC-DB` is associated with an Application Security Group named `ASG-DB`. `Subnet-App` is associated with a Network Security Group named `NSG-Subnet-App`.

The inbound security rules for `NSG-Subnet-App` are configured as follows:
- Priority: 130130 | Source: 172.16.2.0/24172.16.2.0/24 | Port: 443443 | Destination: `ASG-Web` | Action: Allow

The inbound security rules for `NSG-NIC-Web` are configured as follows:
- Priority: 110110 | Source: `ASG-DB` | Port: 443443 | Destination: * | Action: Deny
- Priority: 210210 | Source: 172.16.2.10172.16.2.10 (the static IP of `VM-DB`) | Port: 443443 | Destination: * | Action: Allow

What is the result when `VM-DB` attempts to establish an HTTPS connection (TCP port 443443) to `VM-Web`?

  1. A
    The connection is established successfully because the subnet-level NSG allows the subnet range and the network interface-level NSG contains an explicit allow rule for the IP address of VM-DB.
  2. The connection is blocked by NSG-NIC-Web because the deny rule at priority 110110 evaluates before the allow rule at priority 210210.Answer
  3. C
    The connection is blocked by NSG-Subnet-App because rules targeting Application Security Groups are only evaluated at the network interface level.
  4. D
    The connection is blocked because Application Security Groups cannot be resolved across different subnets within the same virtual network.

Answer

The connection is blocked by NSG-NIC-Web because the deny rule at priority 110110 evaluates before the allow rule at priority 210210.
In Azure, inbound traffic is first evaluated by the subnet-level NSG and then by the network interface-level (NIC) NSG. The traffic must be allowed by both levels to succeed. At the subnet level, the rule at priority 130130 allows traffic from 172.16.2.0/24172.16.2.0/24 to the ASG-Web. At the NIC level, rules are processed in priority order (lower numbers first). The deny rule at priority 110110 matches VM-DB (which is associated with ASG-DB) and immediately blocks the traffic, preventing the allow rule at priority 210210 from being evaluated.

Step-by-Step Solution

1
Evaluate the subnet-level NSG (NSG-Subnet-App) for inbound traffic.
The traffic is allowed at the subnet level because VM-DB's IP address (172.16.2.10172.16.2.10) belongs to the 172.16.2.0/24172.16.2.0/24 subnet range defined in the rule with priority 130130, and VM-Web's NIC is associated with ASG-Web.
Azure evaluates subnet-level NSG inbound rules before network interface-level rules.
2
Evaluate the network interface-level NSG (NSG-NIC-Web) for inbound traffic.
The traffic matches both the rule at priority 110110 (source ASG-DB, which contains VM-DB's NIC-DB) and the rule at priority 210210 (source 172.16.2.10172.16.2.10).
After passing the subnet-level NSG, the traffic is processed by the network interface-level NSG rules.
3
Determine the winning rule based on priority in NSG-NIC-Web.
The rule with priority 110110 (Deny) is applied because it has a lower priority number (higher precedence) than the rule with priority 210210 (Allow).
Azure processes security rules sequentially from lowest priority number to highest, and stops processing once a match is found.

Key Concept

Inbound NSG rules are evaluated first at the subnet level, then at the network interface (NIC) level, and rules within each NSG are processed in ascending order of their priority numbers.
Rate this question