Skip to main content

Technical Lab: Associate an ASG to a network interface

Questions​

Question 1 — Multiple Choice​

A security team needs to apply NSG rules that control traffic between virtual machines from different application tiers (frontend, backend, database) without depending on individual IP addresses. What is the direct benefit of using Application Security Groups (ASGs) in this scenario compared to using explicit IP ranges in NSG rules?

A) ASGs replace the NSG, eliminating the need to create individual rules per port.

B) ASGs allow referencing logical groups of VMs in NSG rules, making rules independent of interface IP addresses.

C) ASGs automatically create allow rules between interfaces in the same group, without additional NSG configuration.

D) ASGs encapsulate the NSG and apply security policies directly at the application layer, without network layer interaction.

Question 2 — Technical Scenario​

An administrator associates an ASG named asg-backend to a VM's NIC. Then creates an inbound rule in the NSG that uses asg-backend as destination. When testing connectivity, the expected traffic doesn't reach the VM.

Consider the configuration below:

NSG: nsg-prod
Inbound rule:
  Priority   : 300
  Source     : 10.0.1.0/24
  Destination: asg-backend
  Port       : 8080
  Action     : Allow

VM NIC         : nic-vm-backend
Associated ASG : asg-backend
Associated NSG : nsg-prod (associated to subnet)

What is the most likely cause for the connectivity failure?

A) The ASG asg-backend and the NSG nsg-prod need to be in the same region, and the administrator may have created the resources in different regions.

B) ASGs used as destination in NSG rules only work when the NSG is associated directly to the NIC, not to the subnet.

C) There is a default deny rule with lower priority than 300 blocking traffic before the allow rule is evaluated.

D) An inbound rule with lower numerical priority takes precedence; there may be a deny rule with priority lower than 300 blocking the traffic.

Question 3 — True or False​

A NIC can have multiple ASGs associated simultaneously, as long as all ASGs are in the same region and same virtual network as the NIC.

Question 4 — Technical Scenario​

A VM has two NICs: nic-primary and nic-secondary. The administrator associates the ASG asg-webservers only to nic-primary. An NSG rule uses asg-webservers as destination on port 443.

What is the expected traffic behavior destined to port 443?

A) Traffic will be allowed on both NICs, as the entire VM becomes a member of the ASG when receiving the association on any of its interfaces.

B) Traffic will be allowed only on the IP address associated to nic-primary, as the ASG association is made on the NIC, not the VM.

C) The configuration is invalid because ASGs cannot be used on VMs with multiple NICs.

D) Traffic will be blocked on both NICs until the ASG is associated to all VM interfaces.

Question 5 — Multiple Choice​

When trying to associate an ASG to a NIC via Azure portal, the administrator doesn't find the desired ASG in the list of available options. The VM and ASG were created successfully. Which of the conditions below, if true, correctly explains this limitation?

A) The ASG is associated to another NSG, which prevents its reuse on additional interfaces.

B) The NIC already has three ASGs associated, which is the maximum limit allowed per interface.

C) The ASG was created in a different region from the region where the NIC is located.

D) The ASG doesn't have any NSG rule referencing it, making it ineligible for association.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • ASGs function as logical labels applied to NICs. When referenced in NSG rules (as source or destination), Azure dynamically resolves which IP addresses correspond to the group. This decouples security rules from IP topology, facilitating scalability and maintenance.
  • Alternative A is incorrect because ASGs don't replace NSGs; they are used within NSG rules as source or destination references.
  • Alternative C represents a common misconception: ASGs don't create automatic permissions between members; all traffic policies still need to be explicitly declared in NSG rules.
  • Alternative D confuses ASG with a layer 7 mechanism (WAF or similar); ASGs operate at the network layer as NIC groupers.

Answer Key — Question 2​

Answer: D

Explanation:

  • In NSGs, lower priority number means higher precedence. If there's a deny rule with priority 200, it will be evaluated before the allow rule with priority 300 and will block traffic, regardless of the ASG being correctly configured.
  • Alternative A is factually correct as a general restriction (ASG and NIC must be in the same region), but the scenario doesn't indicate different regions; the presented configuration is apparently valid in this aspect.
  • Alternative B is incorrect: NSGs associated to subnets correctly evaluate rules that reference ASGs as destination, as long as the NIC member of the ASG is in that subnet.
  • Alternative C reverses the logic: default deny rules have high priorities (65500, 65001), meaning they are evaluated last, not first.

Answer Key — Question 3​

Answer: True

Explanation:

  • A NIC can be associated to multiple ASGs simultaneously. This allows the same interface to participate in different logical groupings and be targeted by multiple independent NSG rules.
  • The actual restriction is that all ASGs associated to a NIC must belong to the same region and same virtual network as the NIC. Associating an ASG from a different VNet or another region to the NIC is not supported.
  • This behavior is relevant in architectures where a VM needs to assume multiple roles, such as being simultaneously a member of asg-backend and asg-monitored, receiving distinct rules for each function.

Answer Key — Question 4​

Answer: B

Explanation:

  • ASG association is made on the NIC, not the VM. When the NSG evaluates a rule with asg-webservers as destination, it checks if the NIC receiving the traffic is a member of that ASG. Since only nic-primary is associated to the ASG, only traffic destined to that interface's IP will match the rule.
  • Alternative A represents the most common misconception: treating the VM as the ASG association unit. In practice, the granularity is the NIC.
  • Alternative C is incorrect: VMs with multiple NICs are fully compatible with ASGs; each NIC can have independent associations.
  • Alternative D is also wrong: there's no requirement for uniform association across all NICs of a VM for the rule to work on interfaces that are members.

Answer Key — Question 5​

Answer: C

Explanation:

  • ASGs are regional resources. A NIC can only be associated to ASGs that are in the same region where the NIC (and its VM) were created. If the ASG was provisioned in a different region, it simply doesn't appear as an available option during association, which exactly corresponds to the behavior described in the question.
  • Alternative A is incorrect: an ASG can be referenced by multiple NSGs and associated to multiple NICs without exclusivity restriction.
  • Alternative B reverses the actual restriction: the limit of ASGs per NIC is 20, not 3. Additionally, the scenario doesn't mention saturation of existing associations.
  • Alternative D is incorrect: the absence of NSG rules referencing an ASG doesn't prevent its association to a NIC. Both operations are independent.