{"id":3973,"date":"2026-10-11T18:44:00","date_gmt":"2026-10-11T18:44:00","guid":{"rendered":"https:\/\/www.examtopics.info\/blog\/az-104-nsg-effective-rules\/"},"modified":"2026-10-11T18:48:04","modified_gmt":"2026-10-11T18:48:04","slug":"az-104-nsg-effective-rules","status":"publish","type":"post","link":"https:\/\/www.examtopics.info\/blog\/az-104-nsg-effective-rules\/","title":{"rendered":"Azure NSGs and Effective Rules for AZ-104"},"content":{"rendered":"

A VM stops accepting requests after a subnet is reorganized. An engineer adds a broad allow rule but nothing improves, because traffic is also filtered at the network interface, follows an unexpected route, or never reaches the subnet. Azure network security groups (NSGs) are important AZ-104<\/a> controls, but they are often blamed for failures they cannot cause\u2014or bypassed when they are correctly protecting the workload.<\/p>\n

The useful mental model is a packet crossing boundaries. Security rules decide whether certain traffic may pass; route tables decide where it goes; DNS determines the address a client tries; and the application may have its own authentication and firewall behavior. Diagnose those boundaries individually.<\/p>\n

An NSG evaluates traffic using prioritized rules<\/h2>\n

NSGs contain inbound and outbound security rules with priorities. For custom rules, Azure uses numeric priorities in the supported range; a lower number represents a higher-priority rule. Evaluation stops when a matching rule is found. The source and destination may be addresses, ranges, service tags or application security groups as supported, and the rule also specifies protocol, port and action.<\/p>\n

An engineer who writes an allow rule at a lower effective priority than an existing deny may think the new rule is ignored. In reality the earlier rule already matched. Read priorities and address\/port fields together, not as independent checkboxes. Built-in default rules provide baseline behavior after higher-priority custom rules; do not assume all inbound traffic is allowed just because the VNet is private.<\/p>\n

When an administrator sees an inbound rule at priority 200 and another at priority 500, the lower numeric priority takes precedence for traffic matching that rule. But evaluating a flow requires direction, protocol, source, destination, ports and both relevant NSG associations. A rule that denies TCP 443 inbound is unrelated to an outbound UDP DNS request unless those fields match. Write the five-tuple and the expected allow\/deny decision before opening the portal. This prevents the common error of changing an unrelated broad rule because its display name resembles the broken application.<\/p>\n

Evaluate subnet and NIC associations together<\/h2>\n

NSGs can be associated with a subnet and, in supported deployments, with a network interface. The effective decision depends on the applied rules along that path. An allow at the subnet does not automatically override a deny at the NIC. Treat the combined rule set as the security boundary when troubleshooting one VM.<\/p>\n

For a web tier with three VMs, subnet-wide restrictions may enforce common policy, while a NIC-specific rule adds an exception. Exceptions can become hard to audit. Prefer designing intentional common security rules and use narrow special cases only when the service truly requires them. Name a rule for the permitted business flow instead of describing it as ‘temporary allow’ with no owner or expiry.<\/p>\n

Suppose a subnet NSG allows HTTPS from an operations subnet while a NIC NSG denies it. Both effective policy layers must allow the traffic for the connection to succeed. Removing the subnet restriction won’t repair a deny at the NIC, and granting an app subnet broad inbound access may expand exposure unnecessarily. Inspect both associations and remember that traffic to a VM can be affected by rules at source outbound and destination inbound. A good investigation produces the matched rule name and priority at each policy boundary instead of summarizing the outcome as ‘the network is blocked’.<\/p>\n

Use source, destination and service tags accurately<\/h2>\n

A service tag identifies a Microsoft-managed set of service address prefixes appropriate to the tag. It is not a promise that every connection to or from that service is authorized at the application level. Application security groups can help define a set of NIC-based endpoints for some rules, reducing the need to maintain individual private IP addresses when workloads scale.<\/p>\n

Imagine a three-tier app in which the web tier should call an API on one port and the API should contact a database on another. Define the required flow explicitly, including direction and destination. An inbound permit for the web subnet is not equivalent to an outbound permit from the API tier. If the database service uses private endpoints, include that actual destination and service behavior in the model.<\/p>\n

Service tags describe Azure-maintained address groups, not complete authorization identities. A Storage service tag can simplify matching platform addresses, but it does not prove that the workload has access to one particular storage account or that traffic reaches the intended private endpoint<\/a>. Application security groups can organize NIC-based source\/destination membership for supported traffic patterns, which makes policy less dependent on hard-coded IP addresses. Document the intent and scope of each group and test representative flows when network interfaces are added or moved. Clear membership is more reliable than a rule named ‘allow production’ with an unexplained all-address range.<\/p>\n

Understand stateful traffic without over-permissioning<\/h2>\n

NSGs are stateful: a permitted connection’s return traffic is generally allowed as part of the established flow rather than requiring an unrelated inverse rule for every packet. This does not mean the system should expose all ephemeral ports to the internet. Learn the difference between a client initiating a connection and the server responding.<\/p>\n

When a service changes ports, update only the necessary source\u2013destination\/protocol combinations and verify the change with a test. Broad ‘Any to Any’ permissions hide the true dependency and invite persistent exceptions. They also make incident investigation harder because a later audit cannot distinguish expected traffic from an unreviewed workaround.<\/p>\n

NSGs are stateful for established flows. You generally do not have to create a mirror inbound rule for each legitimate outbound connection return packet, but new connections in the reverse direction are different requests. If a service cannot connect after you add an allow rule, consider existing connection state, source port behavior, host firewall and intermediate appliances. The correct evidence is a new controlled connection test with known endpoints and ports. Changing the NSG repeatedly while reusing a cached connection can mislead the investigator about which rule actually affects traffic.<\/p>\n

Effective security rules explain what a VM sees<\/h2>\n

Azure Network Watcher<\/a> provides effective security rules and IP flow verify in supported cases. Effective rules combine relevant NSG associations; IP flow verify helps identify the rule allowing or denying a specified simulated packet. Those tools provide more evidence than manually reading separate NSG lists and guessing how they compose.<\/p>\n

If a VM permits inbound HTTPS from one corporate address but rejects another, collect both source addresses, destination address, port and protocol. Run the verification from the relevant VM context and compare the matching rule. Do not treat a green NSG result as proof that the application accepts the connection: guest OS firewall, DNS, routing<\/a>, a load balancer and application authorization can still fail later.<\/p>\n

Effective security rules provide the combined view of rules applicable to a NIC, but a matching deny is not always the entire story. Validate with IP flow verify using the exact flow attributes, then inspect routing and DNS if the tool indicates the packet would be allowed. A permitted NSG flow to an unreachable next hop still fails. Conversely, a TCP timeout may be caused by a host firewall even when Azure’s security rules allow it. Maintain a structured sequence: name resolution, effective route, Azure rule, guest rule, service listener, and response path. This converts ‘it times out’ into a defensible diagnosis.<\/p>\n

NSGs do not route packets or decrypt applications<\/h2>\n

An NSG cannot make a packet reach a service when an effective route sends it to the wrong next hop. Conversely, a correct route does not bypass a security rule. If the client resolves a hostname to a public address rather than a private endpoint, the expected NSG flow may not even be the one being exercised. Diagnose name resolution, effective routes and reachability before modifying rules.<\/p>\n

NSGs also do not inspect HTTP paths or perform the application-layer behavior of a web application firewall. Application Gateway or another suitable service addresses a different part of an HTTP architecture. Don’t confuse a network firewall, a network security group and a web application firewall simply because they all have ‘allow’ or ‘deny’ concepts.<\/p>\n

Migrate obsolete logging assumptions<\/h2>\n

Flow logs are useful for understanding observed network traffic, but Microsoft’s NSG flow-log feature is on a retirement path. Official guidance says new NSG flow logs are no longer supported and existing deployments should migrate toward virtual-network flow logs ahead of the published retirement date. A new tutorial that teaches creating NSG flow logs without that context would be misleading.<\/p>\n

For a production investigation, identify which telemetry the subscription actually produces, how long it is retained and whether it can support the question asked. A record that a connection was attempted is different from proof that an application processed the request. Keep security events, flow telemetry and application response logs correlated by time and network identifiers.<\/p>\n

Practice an AZ-104 security-rule incident<\/h2>\n

Build two disposable VMs in separate subnets with narrowly defined traffic. Use a test service to establish a baseline and add a controlled deny at a known priority. Compare the subnet and NIC effective rules and use IP flow verify where supported. Restore access without adding an unrestricted network-wide permit.<\/p>\n

Now introduce an intentionally wrong route or hostname and observe that changing NSG rules no longer helps. Document the exact point at which connectivity fails. The lesson is a method: start from a real packet tuple, evaluate security, routing, DNS and guest behavior in order, and make the smallest change that restores only the intended flow.<\/p>\n

Deploy two small test VMs in separate subnets with no public management ports. Create a deliberately narrow web service listener between them and confirm the initial flow. Add one subnet deny and use effective rules\/IP flow verify to identify the exact match, then restore the intended allow. Repeat with the deny at the NIC to illustrate overlapping associations. Capture both the Azure rule decision and the guest service’s listener status. Remove training rules at the end and compare the network state with the original baseline so the exercise does not leave hidden access changes.<\/p>\n","protected":false},"excerpt":{"rendered":"

Read Azure Network Security Group priorities, subnet\/NIC evaluation and effective rules without mistaking NSGs for routing or application firewalls.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,10],"tags":[],"class_list":["post-3973","post","type-post","status-publish","format-standard","hentry","category-certifications","category-networking"],"_links":{"self":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/comments?post=3973"}],"version-history":[{"count":1,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3973\/revisions"}],"predecessor-version":[{"id":3999,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/posts\/3973\/revisions\/3999"}],"wp:attachment":[{"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/media?parent=3973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/categories?post=3973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examtopics.info\/blog\/wp-json\/wp\/v2\/tags?post=3973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}