An enterprise deploys a virtual network named `VNet-Prod` containing two subnets: `Subnet-App` () and `Subnet-Data` (). 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: | Source: | Port: | Destination: `ASG-Web` | Action: Allow
The inbound security rules for `NSG-NIC-Web` are configured as follows:
- Priority: | Source: `ASG-DB` | Port: | Destination: * | Action: Deny
- Priority: | Source: (the static IP of `VM-DB`) | Port: | Destination: * | Action: Allow
What is the result when `VM-DB` attempts to establish an HTTPS connection (TCP port ) to `VM-Web`?
- AThe 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.
- The connection is blocked by NSG-NIC-Web because the deny rule at priority evaluates before the allow rule at priority .Cevap
- CThe connection is blocked by NSG-Subnet-App because rules targeting Application Security Groups are only evaluated at the network interface level.
- DThe connection is blocked because Application Security Groups cannot be resolved across different subnets within the same virtual network.