An Azure network security group can be configured exactly as intended and still fail to provide the security boundary the architecture claims. The rule may be attached at the wrong scope, an application security group may not contain the interfaces the team assumes, a higher-level security admin rule may change evaluation, or the protected workload may use a path the rule set never considered. The important question is not whether the NSG exists. It is whether the effective traffic policy matches the application’s trust model.
For AZ-104, NSGs and application security groups (ASGs) are core Azure administration concepts. In production, they become a control-design problem: what boundary is being protected, where should enforcement occur, how should application roles be represented, and what evidence proves that an unexpected flow is actually denied?
Imagine a three-tier application with web, business logic, and database virtual machines. The design intent is simple: internet users reach the web tier, web reaches business logic, business logic reaches the database, and direct web-to-database traffic is denied. That statement is the security policy. NSGs and ASGs are implementation tools for expressing it.
NSGs enforce traffic policy; ASGs describe application membership
An NSG contains ordered inbound and outbound security rules. Rules can match protocol, source, destination, ports, service tags, and application security groups. The NSG can be associated with a subnet, a network interface, or both, depending on the design. Azure then evaluates the effective rule set for the traffic.
An ASG does something different. It groups network interfaces so rules can refer to an application role rather than a list of IP addresses. A rule can say that members of the web ASG may reach members of the business-logic ASG on a specific port. This reduces the operational burden of updating rules every time a VM receives a different private address.
The distinction matters: an ASG does not filter traffic by itself. It gives an NSG rule a logical source or destination. Treating ASGs as independent security controls creates a gap between the diagram and the effective policy.
Control placement should follow the boundary the team actually wants to enforce
A subnet-level NSG applies a common policy to resources in that subnet. A NIC-level NSG can add or refine control for an individual interface. Applying both can be valid, but it increases the number of rule sets an operator must reason about when diagnosing a flow.
For a clean application design, subnet boundaries often align with security zones or tiers. That makes policy easier to understand: the database subnet has one consistent inbound model, the application subnet has another, and exceptions are rare. NIC-level rules can then be reserved for cases where the individual host genuinely needs different treatment.
The broader principles behind access-control lists help explain ordered allow/deny logic, but Azure adds cloud-specific objects such as service tags, ASGs, and platform-provided default rules. Administrators need to reason about the effective Azure policy rather than transplanting a router ACL mental model unchanged.
ASGs reduce IP maintenance, but their membership still has hard boundaries
ASGs are useful because application identity is more stable than individual IP addressing. A VM can be replaced and its new NIC added to the same ASG, preserving the policy. That is especially valuable in environments where infrastructure is recreated frequently.
Microsoft documents an important constraint: the network interfaces in an ASG belong within the same virtual network context required by the ASG rules. A team cannot treat one ASG as a universal enterprise label spanning arbitrary VNets. When an architecture crosses VNet boundaries, the security design needs another abstraction or enforcement point.
This becomes visible in hub-and-spoke designs. The application may be described consistently across spokes, but centralized policy may belong in Azure Firewall, a network virtual appliance, Virtual Network Manager security admin rules, or another control whose scope matches the intended boundary.
Priority numbers are simple; effective policy is not
Within an NSG, lower priority numbers are evaluated before higher ones. A matching allow or deny rule ends evaluation for that direction. NSGs are stateful: return traffic for an established allowed flow does not require a mirror-image rule in the opposite direction. That behavior is easier to reason about when the distinction between stateful and stateless access control is explicit. The trap is assuming the NSG is the only policy layer. Azure Virtual Network Manager security admin rules can be evaluated before NSG rules, and operating-system firewalls or application listeners can still deny traffic after Azure networking allows it.
A design review should therefore distinguish platform reachability from application authorization. An NSG can allow TCP 443 to a VM while the service is not listening. Conversely, the application can be healthy while an upstream rule blocks the packet before it arrives. Both symptoms look like “the site is down,” but the evidence is different.
Network-heavy security decisions also overlap with AZ-700 and, when the question is explicitly about protection and security architecture, SC-500. Those relationships are useful because NSGs are one layer in a larger Azure network-security system, not an isolated feature.
The most dangerous rule is often the broad allow added during an incident
Operational pressure creates policy debt. A service stops communicating, an administrator adds a broad allow rule to restore service, and the temporary rule remains for months. Because the application works afterward, the exception can become invisible until an audit or incident reveals the enlarged trust boundary.
Every emergency rule should therefore have an owner, reason, expiration expectation, and follow-up validation. The team should return after recovery, identify the exact flow that was needed, and reduce the rule to the smallest appropriate source, destination, protocol, and port scope.
Using ASGs can make that cleanup easier because the rule can refer to application roles rather than unstable IP lists. Service tags can similarly reduce maintenance when the destination is a supported Azure service. The objective is not the fewest rules; it is the clearest policy with the smallest justified access.
Verification should simulate the flow the architecture claims to control
Azure Network Watcher provides evidence tools that are much stronger than reading a rule table by eye. IP flow verify can test whether a specific TCP or UDP flow would be allowed or denied and identify the rule responsible. NSG diagnostics can evaluate supported Azure resources and include both NSG and Virtual Network Manager security admin rules in the analysis.
Effective security rules are also valuable because they show the combined result of rules applied to a network interface. That helps when a subnet NSG and NIC NSG interact in ways that are not obvious from either object alone.
A practical test for the three-tier application should include both expected and forbidden flows. Prove that web-to-business traffic succeeds, business-to-database succeeds, and web-to-database is denied. A security control is more credible when the team has evidence for the denial path, not only for the traffic that is supposed to work.
Flow telemetry is changing, so current operations should not be built around retiring NSG flow logs
Historically, NSG flow logs were a common source of traffic evidence. Microsoft has announced their retirement for September 30, 2027, and new NSG flow logs can no longer be created. Current designs should move toward virtual network flow logs and the broader Network Watcher monitoring model instead of building new dependencies on a retiring feature.
This is exactly the kind of current-state detail that matters operationally. An article or runbook written years ago may tell an administrator to enable NSG flow logs as if they were the preferred new deployment. The control objective—observing network flows—remains valid, while the implementation changes.
Logging should answer security questions such as which sources are reaching sensitive subnets, whether denied flows increased after a deployment, and whether a new rule created unexpected lateral communication. Telemetry is useful when it is tied back to the intended trust boundary.
Centralized firewalls and NSGs should have different jobs
An NSG is excellent for distributed layer-3 and layer-4 filtering close to subnets and interfaces. A centralized firewall can add inspection, logging, threat intelligence, application-level controls, and cross-network policy. Using both can be appropriate when each layer has a clear role.
The failure mode is duplicated policy with no ownership model. If the same flow is independently controlled in an NSG, Azure Firewall, an NVA, and the guest firewall, operators may have to inspect four different teams’ rules to understand one outage. Defense in depth should add independent security value, not merely duplicate configuration.
The existing discussion of Azure Firewall is useful for understanding that centralized layer. A strong design can then use NSGs for local segmentation while the firewall handles the policies that genuinely require central inspection or broader scope.
Security design should survive routine infrastructure change
Applications scale, VMs are replaced, IPs change, and subnets are reorganized. A policy that depends on hand-maintained IP addresses is likely to drift. ASGs, service tags, infrastructure as code, and consistent subnet design can make the policy more resilient to normal change.
Change review should also test whether a new resource actually joined the expected ASG. An automation error that deploys a database VM without the database ASG can silently bypass the rule logic the architecture assumes. Membership is part of the control and should be monitored or validated.
The same principle applies to ownership. Application teams should know which network role their resources require, while the platform or network team should know who can change shared NSGs and global security rules. Clear ownership prevents “temporary” exceptions from becoming permanent architecture.
Within the Azure Administrator Associate path, the most durable mental model is to start with application relationships. Web may talk to application. Application may talk to database. Management may enter through an approved administration path. Everything else should be denied unless there is a documented reason.
Then map those relationships to subnets, ASGs, service tags, and NSG rules. Use diagnostics to prove representative allows and denies. Add centralized controls only where they provide a distinct security function. Review broad rules after incidents, and keep telemetry aligned with the current Azure logging model.
When the team can explain the policy in application language and prove it with effective-rule evidence, NSGs and ASGs are doing their job. When the only explanation is “rule 310 allows 10.2.0.0/16,” the implementation may be correct today, but the security intent is already getting lost.
