Skip to main content

Technical Lab: Create an Application Security Group (ASG)

Questions​

Question 1 — Multiple Choice​

You are designing security rules for a multi-tier application hosted in an Azure virtual network. The security team requires that only VMs from the application tier can initiate connections to VMs in the database tier, regardless of the IP addresses assigned to these VMs.

Which approach meets this requirement in the most sustainable way over time?

A) Create NSG rules using the private IP addresses of each database tier VM as the destination.

B) Create an ASG for the application tier VMs and another for the database tier VMs, and reference these ASGs in the NSG rules.

C) Associate an NSG directly to each NIC of the database tier VMs, allowing traffic only from the application tier subnet.

D) Use user-defined routes (UDR) to redirect traffic between tiers through a firewall, eliminating the need for NSG rules.

Question 2 — Technical Scenario​

An engineer configured the following environment:

  • ASG called asg-webservers with three associated VMs
  • ASG called asg-dbservers with two associated VMs
  • Inbound NSG rule on the subnet:
    • Source: asg-webservers
    • Destination: asg-dbservers
    • Port: 1433
    • Action: Allow

When testing connectivity, one of the VMs in asg-dbservers does not receive connections on port 1433 from asg-webservers. The other four VMs work correctly.

What is the most likely cause of the problem?

A) The NSG was not associated to the problematic VM's NIC, only to the subnet.

B) The problematic VM's NIC was not added to the ASG asg-dbservers.

C) The NSG rule does not support ASGs as destination when the NSG is associated to the subnet.

D) The ASG asg-dbservers has reached the maximum allowed member limit.

Question 3 — True or False​

A single NIC can be associated to multiple ASGs, as long as all these ASGs are in the same virtual network.

True or False?

Question 4 — Technical Scenario​

An administrator tries to create an NSG rule with the following configuration:

Source:      asg-frontend   (VNet: vnet-prod, region: East US)
Destination: asg-backend    (VNet: vnet-dev,  region: East US)
Port:        8080
Action:      Allow

Both VNets are connected via VNet Peering. The Azure portal returns an error when trying to save the rule.

What is the reason for the error?

A) VNet Peering does not allow the use of ASGs in NSG rules between distinct VNets.

B) ASGs referenced in the same NSG rule must belong to the same virtual network.

C) Port 8080 is not allowed in rules that use ASGs as both source and destination simultaneously.

D) ASGs can only be used in outbound rules when referenced as destination.

Question 5 — Multiple Choice​

When comparing the use of ASGs with the use of IP prefixes as source or destination in NSG rules, which statement correctly describes a limitation of IP prefixes that ASGs resolve?

A) IP prefixes cannot be used in NSG rules associated to subnets, only to NICs.

B) IP prefixes require manual rule updates whenever a VM's IP address changes or new VMs are added to the logical group.

C) IP prefixes do not support IPv6 traffic within Azure virtual networks.

D) IP prefixes cannot be combined with service tags in the same NSG rule.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

ASGs allow grouping VMs under a logical identifier and referencing that identifier directly in NSG rules. By creating asg-appservers and asg-dbservers and using them as source and destination, the rule remains valid regardless of reassigned IPs, replaced VMs, or scaling.

Alternative A creates direct coupling to IP addresses, which requires constant maintenance. Alternative C uses subnet-level granularity, which is less precise when multiple tiers share the same subnet or when the requirement is granular by function. Alternative D solves the segmentation problem, but with architectural complexity disproportionate to the described need, besides not being the correct mechanism for what ASGs were designed for.

Answer Key — Question 2​

Answer: B

The functioning of an ASG depends directly on the association between each VM's NIC and the corresponding ASG. If a VM's NIC was not added to asg-dbservers, that VM is not recognized as a destination by the NSG rule, even if the VM is in the same subnet or resource group.

Alternative A is a common misconception, but the NSG rule applied to the subnet covers all VMs in it, including the problematic one. Alternative C is incorrect because NSGs associated to subnets fully support ASGs as destination. Alternative D is implausible: the member limit per ASG in Azure is 4,000 NICs per ASG in a subscription, making reaching this limit unlikely in common scenarios.

Answer Key — Question 3​

Answer: True

A NIC can be a member of multiple ASGs simultaneously. The existing restriction is not about the quantity of ASGs per NIC, but about the origin of these ASGs: all ASGs associated to a NIC must belong to the same virtual network as the NIC. This allows modeling overlapping roles, such as a VM that is simultaneously a member of asg-webservers and asg-monitored-vms, receiving rules from both groups.

The non-obvious point here is that this flexibility exists and is intentional, but is conditioned to the VNet scope, not the resource group or subscription scope.

Answer Key — Question 4​

Answer: B

ASGs have virtual network scope. An NSG rule cannot reference two ASGs that belong to different VNets, even if these VNets are connected via peering. The source and destination of the same rule must be in the same VNet when ASGs are used.

Alternative A is incorrect: VNet Peering itself does not prevent the use of ASGs, the limitation is the VNet scope of the ASGs themselves. Alternatives C and D describe restrictions that do not exist in the platform. This scenario represents a common design error when trying to centralize NSGs in multi-VNet environments without considering the scope of ASGs.

Answer Key — Question 5​

Answer: B

The central limitation of IP prefixes in NSG rules is operational: any change in a VM's IP address or addition of a new VM to the logical group requires manual rule updates. ASGs solve exactly this by decoupling the logical identity of the group from IP addressing. Associating the NIC to the ASG is the only step necessary for the VM to be covered by existing rules.

Alternatives A, C, and D describe limitations that do not correspond to the actual behavior of the platform. Alternative B captures the maintenance problem that motivated the creation of the ASG feature, making it the technically grounded answer.