7.1 Network Security Groups and Application Security Groups

Why NSGs and ASGs Matter on SC-500

Under Secure storage, databases, and networking, the SC-500 blueprint explicitly measures implement and manage network security groups (NSGs) and application security groups (ASGs) and evaluate effective security rules by using Azure Network Watcher diagnostics. This section is the foundation for every later network control: Virtual Network Manager security admin rules sit above NSGs, Azure Firewall inspects at different layers, and private endpoints still depend on correct NSG intent when policies are enabled.

NSGs filter IPv4/IPv6 traffic between Azure resources in virtual networks using allow/deny rules at Layer 3 and Layer 4. They do not terminate TLS, inspect HTTP bodies, or replace identity controls—think of them as programmable firewall ACLs attached to subnets and network interfaces.

---

Anatomy of an NSG Rule

Each custom security rule has the properties exam stems love to mix:

Rules are matched on the five-tuple: source address, source port, destination address, destination port, protocol. You cannot place two rules with the same priority and direction.

Stateful behavior: NSGs are stateful. If you allow outbound TCP 443, return traffic for that established flow is permitted without a matching inbound allow. You only need an inbound allow when the client initiates from outside. Conversely, allowing inbound 443 does not require a separate outbound rule for responses.

Flow records and rule changes: Existing connections keep flowing based on the connection state even if you later remove the allow rule. New connections see the updated policy. Exam scenario: closing an SSH allow mid-session leaves the active SSH session up until disconnect; a new SSH attempt is blocked.

Augmented security rules let one rule list multiple IPs/CIDRs and multiple ports—prefer them with service tags and ASGs so you do not maintain long IP lists.

---

Default Security Rules (Memorize the Intent)

Azure injects default rules into every NSG. You cannot delete them; you override with lower-number custom rules.

Inbound defaults

Outbound defaults

Exam trap: Because AllowVNetInBound permits free east-west traffic inside the VirtualNetwork tag, micro-segmentation requires explicit Deny (and selective Allow) custom rules. Leaving only defaults means any NIC in the VNet (subject to other NSGs) can talk to any other on any port—unsafe for production tiering.

Service tags (VirtualNetwork, Internet, Storage, Sql, AzureLoadBalancer, and many more) abstract Microsoft-managed prefix lists so rules stay correct as Azure IP ranges change.

---

Subnet Association vs NIC Association

You can associate an NSG with:

Both apply when present. Traffic is evaluated against the effective combination of subnet NSG and NIC NSG. The practical model:

1. Inbound: traffic must be allowed by the subnet NSG and the NIC NSG (when both exist).
2. Outbound: same dual-check pattern for leaving the NIC and the subnet.

Design pattern: Put broad, shared rules (deny RDP/SSH from Internet, allow HTTPS from load balancer) on the subnet NSG. Put exceptions or extra hardening on the NIC NSG only when needed. Prefer subnet-level policy for scale; overuse of unique NIC NSGs becomes unmanageable.

Scenario: A web subnet NSG allows 443 from Internet. One VM also has a NIC NSG that denies 443. That VM will not serve public HTTPS even though neighbors will—the NIC deny wins for that interface.

---

Application Security Groups (ASGs)

ASGs group NICs by role so security policy follows application structure instead of IP addresses.

Classic three-tier example (Microsoft’s reference pattern):

Because AllowVNetInBound is wide open, you typically add:

1. High-priority Allow from AsgLogic to AsgDb on 1433.
2. Slightly lower-priority Deny of any source to AsgDb on 1433 (or broader deny).

Only NICs that are members of the ASG named in a rule are affected by that rule. An NSG associated to a subnet still only applies ASG-based rules to matching members.

ASG constraints (exam-critical)

• All NICs in one ASG must be in the same virtual network.
• If a rule uses ASG as both source and destination, both ASGs’ NICs must live in that same VNet.
• A NIC can belong to multiple ASGs (within subscription limits).
• Prefer ASGs + service tags over IP churn when VMs scale in/out.

Micro-segmentation pattern: Combine subnet NSG baselines + ASG-based east-west allows + explicit denies for sensitive tiers. Pair with Just-in-Time VM access and Azure Bastion (compute chapter) so you never leave 3389/22 open to Internet.

---

Effective Security Rules and Network Watcher

When subnet NSG, NIC NSG, and (later) Virtual Network Manager security admin rules all exist, humans cannot reliably “eyeball” the result. Azure Network Watcher → Effective security rules shows the aggregated inbound and outbound rules applied to a specific NIC, including admin rules from Azure Virtual Network Manager.

Use effective rules for:

• Troubleshooting “why is this port blocked?”
• Auditing against a prescribed security baseline
• Confirming ASG membership actually expanded to the expected prefixes

SC-500 may phrase this as evaluate effective security rules using Network Watcher diagnostics—do not answer “read only the subnet NSG blade” when both NIC association and admin rules may apply.

---

Platform Footnotes That Bite in Exams

• Host node services (DHCP, DNS, IMDS via 168.63.129.16 / related platform paths) are generally not blocked by ordinary NSG mistakes unless you explicitly target platform service tags such as AzurePlatformDNS or AzurePlatformIMDS.
• Load-balanced VMs: source addresses in NSG evaluation are the original client, not the load balancer front end (except health probes, which use AzureLoadBalancer).
• Stateful flows mean “deny later” is not a kill switch for already established sessions—plan operational break-glass accordingly.

---

Worked Scenario: Segment a Payment App

Requirements: Internet users hit web VMs on 443 only; app tier accepts only web tier on 8080; SQL accepts only app tier on 1433; no direct Internet RDP/SSH.

Correct approach:

1. Subnet-per-tier (Web, App, Data) with a shared NSG pattern or one NSG per subnet.
2. Create ASGs AsgWeb, AsgApp, AsgDb; assign NICs.
3. Custom inbound rules (priorities 100–200 range): allow Internet→AsgWeb:443; allow AsgWeb→AsgApp:8080; allow AsgApp→AsgDb:1433.
4. Deny rules after allows to block residual tier jumps (for example deny *→AsgDb:1433 with lower priority than the app allow).
5. Never open 22/3389 from Internet; use Bastion/JIT.
6. Validate with Network Watcher effective security rules on a sample NIC from each tier.

SC-500 Exam Traps (NSG/ASG)

• Lower priority number wins—priority 100 beats 200.
• Defaults allow full VNet communication; segmentation is not free.
• NSG is not a WAF and does not replace Azure Firewall application rules.
• ASGs are not cross-VNet identity groups.
• Effective rules > reading a single NSG when dual association or admin rules exist.
• Stateful: do not invent reverse rules for return traffic on allowed flows.