AZ-104 Practice Question 39: Application Security Groups
Microsoft Azure Administrator Associate (AZ-104) · Test 4 · question 9 of 10
The web tier of an application runs on VMs spread across two subnets of VNet-Prod. VMs are re-created regularly by a pipeline, and each rebuild changes their private IP addresses. The team maintains network security group rules that list those addresses explicitly, and the rules are constantly out of date, sometimes blocking healthy servers, sometimes leaving stale addresses allowed.
What should you do to stop maintaining IP addresses in the rules?
Show answer and explanation
Answer:
Application security groups exist for this problem: they "enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses." A rule naming an ASG applies to whichever network interfaces are members at the time, so a rebuilt VM is covered the moment its NIC joins the group. The constraint is satisfied here: all NICs in an ASG must live in the same virtual network, and both subnets are in VNet-Prod. Microsoft's own advice is to "create rules using service tags or application security groups, rather than individual IP addresses or ranges of IP addresses, when possible."
Option A freezes the symptom instead of removing it. Static addresses still have to be added to and removed from rules every time the fleet changes size, and the pipeline would have to allocate them.
Option C misunderstands service tags. A service tag represents Microsoft-managed prefixes for an Azure *service* (Storage, AzureLoadBalancer, Internet) not your own VMs' addresses.
Option D is a real workaround but a poor design: it forces network topology to follow application tiering, wastes the second subnet, and still breaks as soon as another workload shares the subnet.
Reference: Application security groups