Cascade Regional Airlines wants an NSG rule that allows the reservations-app VMs to reach the payment-processing VMs on port 443, without hardcoding IP addresses since those VMs are added and removed as the fleet autoscales. What should the rule use as its source and destination?
Select an answer to reveal the explanation.
Short Explanation
Application security groups let you write a rule about roles, not IP addresses — ‘reservations-app talks to payment-processing on 443’, full stop. Add or remove a VM from the group and the rule just keeps working, with no IP list to babysit.
Full Explanation
Application security groups (ASGs) let an NSG rule reference a logical group of VM NICs by role — such as ‘reservations-app’ or ‘payment-processing’ — instead of a specific IP address or range, and VMs can be added to or removed from an ASG as they scale without ever touching the NSG rule itself. Referencing the two ASGs as source and destination in a single NSG rule gives Cascade exactly the dynamic, role-based access control the autoscaling reservations fleet needs. The service-tag distractor is wrong because service tags represent Microsoft-managed groups of IP ranges for Azure platform services (like Storage or SQL), not a customer's own application-tier VMs. The user-defined-route distractor confuses routing (choosing a network path) with security filtering (deciding whether traffic is permitted); a route does not enforce access control on its own. The DNS-name-allowlist distractor invents a filtering mechanism NSGs do not support; NSG rules match on IP address, port, protocol, service tag, or ASG, never on DNS names directly. ASGs are scoped to VMs within the same virtual network, so this pattern only works as long as both tiers remain in one VNet or peered VNets with the ASGs shared appropriately.