Technical Lab: Associate a NSG to a Resource
Questions
Question 1 — Multiple Choice
An infrastructure team needs to apply a Network Security Group (NSG) to control traffic for a specific virtual machine without affecting other VMs in the same subnet. What is the correct approach?
A) Associate the NSG to the subnet, as it is the only method supported by Azure.
B) Associate the NSG to the VM's network interface (NIC), as it allows granular control per individual resource.
C) Associate the NSG to the Public IP Address resource linked to the VM.
D) Associate the NSG to the Virtual Network (VNet), as this ensures coverage of all internal resources.
Question 2 — Technical Scenario
An administrator associated an NSG to the snet-backend subnet and another NSG to the NIC of a VM called vm-api within the same subnet. The subnet NSG has the following inbound rule:
Priority: 200
Protocol: TCP
Destination Port: 8080
Action: Deny
The NIC NSG has:
Priority: 100
Protocol: TCP
Destination Port: 8080
Action: Allow
An external client tries to connect to port 8080 of vm-api. What happens?
A) The connection is allowed, as the NIC's Allow rule has higher priority (lower number) and overrides the subnet NSG.
B) The connection is blocked, as for inbound traffic the subnet NSG is evaluated first, and the Deny rule prevents passage before reaching the NIC.
C) Azure returns a conflicting configuration error and neither rule is applied.
D) The connection is allowed, as Allow rules always prevail over Deny rules when there are multiple associations.
Question 3 — True or False
It is possible to associate the same NSG simultaneously to multiple subnets and multiple network interfaces, as long as all resources are in the same Azure region.
Question 4 — Technical Scenario
A VM was created with two NICs: nic-primary and nic-secondary. The team associated an NSG called nsg-restrictive only to nic-primary. After configuration, it was observed that unauthorized traffic was still reaching the VM through nic-secondary.
What is the root cause of the problem and what is the correct action?
A) The NSG associated to one NIC automatically propagates to all NICs of the same VM; the problem is in misconfigured rules in nsg-restrictive.
B) NSGs cannot be associated to NICs of VMs with multiple interfaces; the association must be done exclusively on the subnet.
C) The NSG association to one NIC protects only that interface; it is necessary to associate a separate NSG to nic-secondary or to the corresponding subnet.
D) The behavior is expected, as NSGs only filter outbound traffic on secondary NICs.
Question 5 — Multiple Choice
Which of the statements below correctly describes an association restriction for NSGs in Azure?
A) An NSG can be associated to resources in different VNets, as long as they are in the same subscription.
B) An NSG can only be associated to subnets or NICs that are in the same region as the NSG.
C) An NSG associated to a subnet is automatically inherited by all VNets in peering with that subnet.
D) An NSG can only be associated to one resource at a time, either a subnet or a NIC.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Explanation:
- NSGs can be associated to subnets or network interfaces (NICs), these being the only two supported options. Associating to the NIC applies rules exclusively to that VM, without interfering with other VMs in the subnet.
- The main error in the distractors is pointing to invalid resources: Public IP and VNet do not support direct NSG association. Subnets do support it, but the question requires scope per individual VM.
- Choosing alternative A would imply unnecessary rule overhead and impact on the entire subnet, violating the principle of least privilege.
Answer Key — Question 2
Answer: B
Explanation:
- The NSG evaluation order in Azure for inbound traffic is deterministic: the subnet NSG is processed first; only if traffic is allowed at this layer does it reach the NIC NSG.
- The priority number (100 vs 200) is only relevant between rules within the same NSG, not between different NSGs. Therefore, the Allow rule on the NIC is never evaluated.
- Alternative A confuses the concept of intra-NSG priority with inter-NSG precedence. Alternative D is technically incorrect: the action (Allow/Deny) does not determine precedence between NSGs.
Answer Key — Question 3
Answer: True
Explanation:
- An NSG is a reusable resource: it can be associated to multiple subnets and multiple NICs simultaneously, regardless of how many there are.
- The real restriction is region: the NSG must be in the same region as the resources it is associated to. There is no subscription or VNet restriction for this type of reuse.
- This behavior is intentional and allows standardization of security policies at scale, without rule duplication.
Answer Key — Question 4
Answer: C
Explanation:
- In Azure, each NIC is an independent resource. Associating an NSG to one NIC protects only that interface; there is no automatic propagation to other NICs of the same VM.
- The correct solution is to associate an NSG to
nic-secondarydirectly, or associate an NSG to the subnet it is connected to, thus covering the ingress path for that interface. - Alternative A describes behavior that does not exist in Azure. Alternative B is wrong as NICs of multi-interface VMs support NSGs normally. Alternative D reverses the logic: NSGs filter both inbound and outbound traffic on NICs, without distinction between primary and secondary.
Answer Key — Question 5
Answer: B
Explanation:
- The fundamental NSG association restriction is region: the NSG and the associated resource (subnet or NIC) must belong to the same Azure region. There is no subscription or VNet restriction.
- Alternative A is incorrect as it mixes the absence of subscription restriction with the absence of region restriction, which actually exists.
- Alternative C describes non-existent behavior: NSGs do not propagate through VNet peering.
- Alternative D is wrong as an NSG can be associated to multiple resources simultaneously, this being one of its main operational values.