# NSG rule

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/nsg-rule

## Quick definition

An NSG rule is like a firewall rule for Azure cloud networks. It decides if data packets can enter or leave a virtual machine or other Azure service. Each rule specifies a source, destination, port, and protocol, and then either allows or denies that traffic. NSG rules are processed in priority order, with the highest priority rule applied first.

## Simple meaning

Imagine you are the security guard at the entrance of a large office building. Your job is to check every person who wants to enter or leave the building. You have a clipboard with a list of rules. The first rule might say: allow all employees with a valid badge to enter. Another rule might say: deny anyone without a badge. A more specific rule might say: allow only IT staff to enter the server room on the third floor.

In cloud computing, an NSG rule works the same way but for data traffic. An NSG, or Network Security Group, is a virtual security guard for your Azure virtual network. Each NSG rule is an instruction that says: if traffic comes from this IP address, going to this destination, using this protocol, and this port number, then either allow it or deny it.

For example, a common rule might say: allow all incoming web traffic on port 80 and port 443 from the internet to your web server. Another rule might say: deny all other incoming traffic from the internet. These rules are numbered in priority order, from highest (lowest number) to lowest (higher number). Azure processes the rules from top to bottom, and once a rule matches, it stops checking further rules.

This is very important because without NSG rules, your Azure resources would be completely open to the internet, which is a huge security risk. With properly configured NSG rules, you can lock down your resources so only the traffic you want is allowed. Think of it as setting up custom locks on different doors of your cloud house.

## Technical definition

An NSG rule, or Network Security Group rule, is a fundamental component of network security in Microsoft Azure. NSGs are stateful, meaning they track the state of network connections and automatically allow return traffic for any allowed inbound or outbound flow. Each NSG contains a list of security rules that are evaluated in priority order, from lowest numerical priority to highest. Every rule has the following properties: priority (a number from 100 to 4096, with lower numbers indicating higher priority), action (allow or deny), direction (inbound or outbound), protocol (TCP, UDP, or Any), source address prefix (IP address, CIDR range, service tag, or application security group), source port range, destination address prefix, destination port range, and name.

When a network packet arrives at a virtual network interface (NIC) or subnet that has an NSG associated, Azure evaluates the packet against all rules in the NSG. The evaluation starts with the rule that has the lowest priority number (highest priority). If a match is found, the action in that rule is applied, and no further rules are evaluated. If no rule explicitly matches, the default rules apply. Azure NSGs come with built-in default rules for both inbound and outbound traffic. For inbound, the default rules allow traffic from within the virtual network and from Azure load balancer health probes, and deny all other inbound traffic. For outbound, the default rules allow traffic to the virtual network and to the internet, and deny all other outbound traffic.

NSG rules can be associated at two levels: subnet level and NIC level. Subnet-level NSGs apply to all resources within that subnet, while NIC-level NSGs apply only to the specific virtual machine or resource attached to that NIC. When both are associated, the rules are evaluated in order: first the subnet-level NSG, then the NIC-level NSG. This allows for a layered security approach. NSG rules are also commonly used with service tags, which are predefined groups of IP addresses for Azure services, making rule creation simpler and more secure. For example, the service tag 'Internet' represents all public internet IP addresses, while 'AzureLoadBalancer' represents Azure's load balancer infrastructure.

In terms of protocols, NSG rules support TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and the wildcard 'Any'. Port ranges can be specified using a single port, a range like 80-443, or the wildcard '*' for all ports. Destination and source address prefixes can be specific IPs, CIDR blocks, service tags, or application security groups (ASGs). ASGs provide a way to group virtual machines logically and reference them in NSG rules without needing to manage individual IP addresses. This is especially useful in dynamic environments where VM IPs change.

## Real-life example

Think of NSG rules like the security policies at a large corporate headquarters. The building has multiple floors, each with different departments. The ground floor has the main lobby, a cafeteria, and a conference center. The second floor has the IT department and the server room. The third floor has the finance and HR teams.

Now, imagine you are the building's security manager. You create a set of rules for who can go where. First, you post a general rule at the main entrance: any visitor must check in at the front desk and get a badge. That is like a default deny rule for inbound traffic. Then, you add a specific rule: all employees with a valid badge can enter the ground floor and first floor. That is like an allow rule for internal traffic.

But for the second floor IT server room, you add a very strict rule: only IT staff with a special key card can enter. That is like an NSG rule that allows traffic only from specific IP addresses or application security groups. For the third floor finance department, you add a rule: only employees from the finance team and the CEO can enter. That is another specific allow rule.

Now, if a visitor shows up and tries to go to the second floor, the security guard checks the rules. The first rule says all visitors must check in, but that happened. The second rule allows all employees to the ground and first floor, but the visitor is not an employee. The third rule specific to the server room denies anyone not on the IT list. So the visitor is stopped at the elevator. This is exactly how NSG rules work: traffic is evaluated against each rule in priority order, and the first match determines the outcome. If no rule matches, a default rule (deny) kicks in.

In Azure, you might have a virtual machine that hosts a web application. You create an NSG rule that allows inbound traffic on port 443 (HTTPS) from the internet, but denies all other inbound traffic. Another rule might allow inbound RDP (port 3389) traffic only from your company's VPN IP range. This way, you lock down the VM completely, just like the building's security locks down the server room.

## Why it matters

NSG rules are critically important in Azure networking because they form the first line of defense for your cloud resources. In a typical enterprise environment, you have multiple virtual machines, databases, and application services that all need to communicate with each other and with the internet. Without NSG rules, all these resources would be exposed to the public internet by default, which is a massive security vulnerability.

In practice, NSG rules allow you to implement the principle of least privilege: only give access to the traffic that is absolutely necessary. For example, you might have a web server that needs to receive HTTP and HTTPS traffic from the internet, but it does not need to receive SSH or RDP traffic from the internet. So you create an NSG rule that allows inbound port 80 and 443 from the internet, and another rule that allows inbound port 22 (SSH) only from your management network. This reduces the attack surface significantly.

NSG rules also help with compliance. Many regulatory standards, such as PCI DSS or HIPAA, require that network access be restricted and controlled. Using NSGs, you can document exactly which traffic is allowed and denied, which is essential for audits. NSGs are free in Azure, so there is no cost reason not to use them.

Another reason NSGs matter is that they can be used to segment your network. For instance, you can have a subnet for front-end web servers and a separate subnet for back-end databases. You can then create NSG rules that allow the front-end subnet to communicate with the back-end subnet only on the database port, while blocking all other traffic between them. This prevents a compromised web server from being used to attack the database directly.

Finally, NSG rules are stateful, which simplifies rule creation. You do not need to create separate rules for return traffic. For example, if you allow outbound traffic to the internet, the NSG automatically allows the return traffic from the internet back to your VM. This reduces the number of rules you need to manage and helps prevent accidental misconfigurations.

## Why it matters in exams

For general IT certification exams that cover Azure, such as Microsoft Azure Administrator (AZ-104), Azure Network Engineer (AZ-700), and Azure Security Engineer (AZ-500), NSG rules are a core topic. These exams expect you to understand not just what an NSG rule is, but also how to configure, prioritize, and troubleshoot them. In the AZ-104 exam, network security groups appear in the 'Manage Azure identities and governance' and 'Implement and manage storage' sections, but most heavily in the 'Configure and manage virtual networking' section. You will encounter questions that ask you to design NSG rules to meet specific security requirements, such as allowing only certain IP ranges to access a VM or blocking all inbound traffic except from a specific source.

In the AZ-700 exam, which focuses on networking, NSG rules are even more detailed. You need to understand how NSGs interact with Azure Firewall, Application Security Groups, and service tags. You may be asked to troubleshoot connectivity issues that arise from misconfigured NSG rules, such as a VM not being able to connect to the internet because an outbound rule is blocking it. Questions often present a scenario where multiple NSGs are associated at the subnet and NIC level, and you must determine which rule takes effect.

In the AZ-500 exam (Security Engineer), NSG rules are part of the 'Implement network security' domain. You will be tested on how to use NSGs to enforce network segmentation and secure traffic flows. You may need to identify the correct combination of NSG rules and Azure Firewall policies to meet a compliance requirement.

Exam question patterns typically include multiple-choice questions where you are given a set of requirements and asked which NSG rule configuration meets them. For example: 'You have a web server VM that needs to receive web traffic from the internet and management traffic from a management subnet. You need to configure NSG rules to allow only HTTP, HTTPS, and RDP from the management subnet. What should you do?' The correct answer would involve creating two inbound rules: one allowing HTTP and HTTPS from any source, and another allowing RDP from the management subnet IP range. You would also need to ensure that the default deny rule remains in place for all other traffic.

Other common question types include ordering rules in the correct priority, understanding the difference between subnet-level and NIC-level NSGs, and recognizing that NSG rules are stateful. You may also be asked to use service tags in NSG rules, such as allowing Azure Load Balancer health probes. Understanding these nuances is critical for passing the exam.

## How it appears in exam questions

In certification exams, NSG rule questions typically fall into three categories: scenario-based design, configuration validation, and troubleshooting.

Scenario-based design questions present a business requirement and ask you to choose the correct set of NSG rules. For example: 'A company has an Azure VM that hosts a web application. The VM must be accessible from the internet on ports 80 and 443. RDP access should only be allowed from the company's headquarters IP range of 203.0.113.0/24. All other inbound traffic should be blocked. What NSG rules should you create?' The correct answer would be to create two inbound rules: Rule 100: Allow TCP port 80 and 443 from any source (Internet). Rule 110: Allow TCP port 3389 from source 203.0.113.0/24. The default deny rule will block everything else. Some questions might ask you to order the rules correctly or might give you a list of rules with priorities and ask if the configuration meets the requirements.

Configuration validation questions might give you a screenshot of NSG rules and ask whether the set up is correct. For instance, if you see a rule that allows RDP from the internet on port 3389 with priority 100, and another rule that denies RDP from the internet with priority 200, the first rule will match, so RDP from the internet is allowed. You need to understand that the lower priority number wins. Another common trap: a rule that allows all traffic (protocol Any, port Any, source Any) with priority 100 will effectively override any higher-numbered deny rules because it matches first.

Troubleshooting questions are common. For example: 'Users report that they cannot connect to a web application hosted on VM1 in Azure. The VM has an NSG associated. The NSG inbound rules are: Rule 100: Allow TCP 80 from Internet. Rule 200: Deny TCP 3389 from Internet. What is the most likely cause of the connectivity issue?' The answer might be that the NSG is not associated with the VM's subnet or NIC, or that the web server service is not running. Or maybe the NSG has an outbound rule blocking the return traffic, but since NSGs are stateful, that is unlikely. Sometimes the question will involve multiple NSGs at the subnet and NIC level, and you need to determine which rule is being applied.

Another pattern: questions about Application Security Groups (ASGs) in NSG rules. For example: 'You have multiple web servers grouped into an ASG called WebServers. You want to allow the WebServers ASG to communicate with a database ASG on port 1433. Which NSG rule should you create?' The correct answer involves creating an outbound rule on the WebServers ASG or an inbound rule on the database ASG, using the ASG as the source or destination.

Finally, some questions test your understanding of service tags. For example: 'You need to allow the Azure Load Balancer to perform health checks on your VM. Which service tag should you use in the NSG rule?' The answer is 'AzureLoadBalancer'. These types of questions require you to not only understand NSG rules but also Azure's networking constructs.

## Example scenario

You are an IT administrator for a small company that hosts a web application in Azure. The application runs on a single virtual machine named WebVM. You need to configure security so that customers can access the web page (ports 80 and 443) from the internet, but you also need to be able to remotely manage the VM using RDP (port 3389) from your office network, which has an IP range of 203.0.113.0/24. No other traffic should be allowed.

First, you create a Network Security Group called WebVM-NSG. Then, you create inbound security rules for the NSG. You set Rule 100 to allow TCP traffic on ports 80 and 443 from any source. You set Rule 110 to allow TCP traffic on port 3389 from the source IP range 203.0.113.0/24. You leave the default inbound rules as they are: allow traffic from the virtual network and from Azure Load Balancer, and deny all other inbound traffic. Because your specific allow rules have lower priority numbers (100 and 110) than the default deny rule (which has priority 65000), the allow rules will be evaluated first and will permit the desired traffic.

Next, you associate the WebVM-NSG with the subnet that contains WebVM. Alternatively, you could associate it directly with the NIC of WebVM for more granular control. After association, you test by browsing to the web page from a public internet connection, and it works. You then try to RDP from your office network, and it also works. You try to SSH (port 22) from the internet, and it fails, as expected.

Later, you realize that your office network uses a VPN that sometimes changes the source IP. To avoid locking yourself out, you create an Application Security Group (ASG) for your management VMs and use that ASG as the source in the NSG rule instead of a fixed IP range. This makes the configuration more flexible and easier to maintain.

This scenario demonstrates the core purpose of NSG rules: to grant access only where needed and block everything else. If you had not created the NSG, your VM would be fully open to the internet, making it vulnerable to attacks. The NSG rule approach is simple but powerful.

## Common mistakes

- **Mistake:** Setting the priority number too high, causing the rule to be ignored because a default rule or another rule with higher priority matches first.
  - Why it is wrong: NSG rules are evaluated in order of priority, from lowest number (highest priority) to highest number (lowest priority). If you create a rule with a priority of 4000, but the default deny rule has a priority of 65000, that is fine. But if you create a rule with priority 2000 that allows traffic, and there is a rule with priority 1000 that denies all traffic, your allow rule will never be reached. The lower number always wins, so a high-numbered allow rule can be blocked by a lower-numbered deny rule.
  - Fix: Always plan your rule priorities carefully. Put explicit allow rules with low priority numbers (like 100, 110) so they are evaluated before any deny rules. Avoid using very high numbers for critical allow rules unless you are sure no lower-numbered rule will block them.
- **Mistake:** Forgetting that NSG rules are stateful and creating unnecessary outbound rules for return traffic.
  - Why it is wrong: Because NSGs are stateful, if you allow inbound traffic from the internet, the NSG automatically allows the return outbound traffic for that connection. You do not need to create a separate outbound allow rule for the response packets. Creating such rules adds complexity and can cause confusion. Some exam questions test this by presenting a scenario where a candidate creates both inbound and outbound rules for the same flow, and the correct answer is that only the inbound rule is needed.
  - Fix: Only create outbound rules when you want to explicitly block or allow outbound traffic initiated from within the network. For return traffic of an allowed inbound connection, trust the stateful nature of NSGs.
- **Mistake:** Associating an NSG at the NIC level when the subnet-level NSG already has a conflicting rule, leading to unexpected behavior.
  - Why it is wrong: When both a subnet-level NSG and a NIC-level NSG are associated with a VM, the subnet rules are evaluated first, then the NIC rules. So if the subnet NSG denies a type of traffic, but the NIC NSG allows it, the traffic will still be denied because the subnet rule was evaluated first. This often leads to confusion when administrators troubleshoot connectivity issues and only look at the NIC NSG.
  - Fix: Always check both subnet-level and NIC-level NSGs when troubleshooting. Understand that the subnet NSG is evaluated first. If possible, avoid duplicating rules at both levels. Use subnet NSGs for broad security policies and NIC NSGs for fine-grained per-VM exceptions.
- **Mistake:** Using the wrong source or destination address prefix, such as using '*' instead of 'Internet' service tag, or using a specific IP when a service tag is more appropriate.
  - Why it is wrong: Using '*' for source means 'any IP address', which is exactly the same as the 'Internet' service tag for inbound traffic. However, for more granularity, using a service tag like 'AzureLoadBalancer' is more correct than allowing the entire internet. Also, if you use a specific IP address but the source changes (e.g., due to NAT or load balancing), your rule may stop working. Service tags are dynamic and maintained by Azure, reducing maintenance overhead.
  - Fix: Use service tags whenever possible for Azure services. For your own networks, use IP address ranges or Application Security Groups. Avoid using '*' when a more specific range is appropriate, as it reduces security.

## Exam trap

{"trap":"The exam presents a scenario where an NSG rule allows all inbound traffic on a specific port, but the user still cannot connect. The question asks for the cause, and one of the options is that the NSG is not stateful. Learners often pick this option because they think NSGs need outbound rules for return traffic.","why_learners_choose_it":"Learners sometimes confuse NSGs with traditional stateful firewalls that require separate outbound rules. They might also remember that some firewalls are stateless (like network ACLs in AWS) and mistakenly think NSGs are also stateless. This misconception leads them to choose the 'not stateful' option.","how_to_avoid_it":"Memorize that NSGs are stateful. This means that if you allow inbound traffic, the outbound return traffic is automatically allowed. If a connection fails despite an inbound allow rule, the issue is likely elsewhere: the rule may not be associated with the correct subnet or NIC, the priority may be too low and a higher-priority deny rule is blocking it, or the VM's operating system firewall itself is blocking the traffic. Always eliminate the simple causes first."}

## Commonly confused with

- **NSG rule vs Azure Firewall:** Azure Firewall is a fully managed, cloud-native network security service that provides application and network-level protection. Unlike NSG rules, which are basic stateful filtering at the subnet or NIC level, Azure Firewall can perform deep packet inspection, application filtering (FQDN), threat intelligence, and logging. NSGs are simpler and free, while Azure Firewall is a premium service with a cost. In exams, you choose NSGs for basic traffic control and Azure Firewall for advanced security needs. (Example: If you only need to allow web traffic to a single VM, use an NSG. If you need to inspect all web traffic for malware and allow only specific URLs, use Azure Firewall.)
- **NSG rule vs Network ACL (in AWS):** AWS Network ACLs are stateless, meaning you must explicitly define rules for both inbound and outbound traffic for each direction separately. In contrast, Azure NSGs are stateful, which automatically handles return traffic. Also, AWS NACLs are applied at the subnet level only, while Azure NSGs can be applied at both subnet and NIC levels. In exams, this distinction is important if you are studying multi-cloud concepts. (Example: In Azure, if you allow inbound HTTP traffic from the internet, the response traffic is automatically allowed. In AWS, you would need a separate outbound rule to allow the response.)
- **NSG rule vs Application Security Group (ASG):** An ASG is not a rule itself, but a logical grouping of virtual machines that can be used as a source or destination in an NSG rule. While NSG rules define Allow/Deny actions, ASGs provide a way to refer to a set of VMs by name rather than by individual IP addresses. For example, instead of listing each web server's IP address in an NSG rule, you can create an ASG for 'WebServers' and use that as the source. This makes rules easier to manage. ASGs are used within NSG rules; they are not a replacement. (Example: You have five web servers. Instead of creating five NSG rules with different source IPs, you create one NSG rule with the source set to the ASG named 'WebServers'.)

## Step-by-step breakdown

1. **Define your security requirements** — Before creating any rules, determine which traffic should be allowed and which should be denied. Consider what services your VM or subnet needs to provide, who needs to access them, and from where. For example, a web server needs inbound HTTP/HTTPS from the internet, but SSH should only be allowed from the management network.
2. **Create a Network Security Group** — In the Azure portal or via CLI, create a new NSG. Give it a meaningful name, such as 'WebVM-NSG' or 'Frontend-Subnet-NSG'. The NSG will initially contain default rules that allow internal virtual network traffic and deny all other inbound traffic. Those can be modified or superseded by your custom rules.
3. **Add inbound security rules** — Add rules to allow the traffic you identified in step 1. Set the priority (lower number = higher priority), choose the action (Allow or Deny), set the source (IP range, tag, or ASG), destination (same), protocol (TCP, UDP, or Any), and port range. For example, add a rule with priority 100 that allows TCP on port 80 and 443 from the 'Internet' service tag.
4. **Add outbound security rules if needed** — By default, outbound traffic to the internet and to the virtual network is allowed. If you need to restrict outbound traffic, add outbound deny rules with appropriate priorities. For example, you might want to block outbound traffic to known malicious IP ranges. Remember, NSGs are stateful, so you do not need outbound rules for responses to allowed inbound traffic.
5. **Associate the NSG with a subnet or NIC** — Associate the NSG with the subnet (applies to all VMs in that subnet) or with the network interface of a specific VM (NIC level). You can also do both for layered security. The association is what activates the rules. Without association, the NSG has no effect.
6. **Test and validate connectivity** — After association, test the rules by attempting to connect to the allowed services. For example, browse to the web server from a public internet connection and verify it works. Then try to connect to a denied port and confirm it is blocked. Use network monitoring tools or Azure's Network Watcher to verify the flow.
7. **Monitor and update rules as needed** — As your environment changes, update your NSG rules accordingly. For example, if a new service is deployed, add new allow rules. If a source IP range changes, update the rule. Regularly review your NSG rules to ensure they still meet your security policies and remove unused rules.

## Practical mini-lesson

In real-world Azure environments, NSG rules are a daily tool for network engineers and cloud administrators. The most common task is creating rules to allow specific traffic while blocking everything else. However, there are several nuances that professionals need to master.

First, understanding rule priority is critical. You might have hundreds of rules in a single NSG, and if any two rules have the same priority, the creation fails. So always leave gaps in numbering. I typically start with priority 100 and increment by 10 for each rule, allowing room for future additions without renumbering everything. This is a standard best practice.

Second, you need to know the difference between subnet-level and NIC-level associations. In a multi-tier application, you might have a subnet for web servers and a subnet for database servers. You associate a subnet-level NSG with the database subnet that only allows traffic from the web server subnet on port 1433 (SQL). Then, for a specific database VM that needs internet access for updates, you associate a NIC-level NSG that allows outbound traffic to the internet. The subnet NSG still blocks other inbound traffic, but the NIC NSG adds the outbound allowance. This layered approach is very powerful.

Third, you should use Application Security Groups (ASGs) to simplify management. Instead of maintaining a list of IP addresses for your web servers, you create an ASG called 'WebServers' and add the VMs to it. Then, in the NSG rule, you use the ASG as the source or destination. If a new web server is added, you simply add it to the ASG, and the rule applies automatically. This is especially valuable in autoscaling environments where VMs come and go.

Fourth, be aware of service tags. Tags like 'Internet', 'AzureLoadBalancer', 'VirtualNetwork', and 'AzureTrafficManager' are frequently used. For example, to allow Azure Load Balancer health probes, you need an NSG rule allowing traffic from the 'AzureLoadBalancer' tag on the health probe port. If you forget this, your load balancer will mark the VM as unhealthy, causing issues.

Finally, troubleshooting connectivity issues often starts with checking NSG rules. Use Azure's Network Watcher to run IP flow verify. This tool tests a specific traffic flow (source, destination, port, protocol) and tells you whether it is allowed or denied, and which NSG rule caused the action. This is invaluable for diagnosing why a connection is failing. Common pitfalls include forgetting to associate the NSG, creating a rule with the wrong direction, or using a port range that doesn't include the actual port.

NSG rules are simple but require careful planning. Always use the principle of least privilege, document your rules, and test thoroughly. This approach will keep your Azure environment secure and your certification exam answers correct.

## Memory tip

Remember 'PAD' for NSG rules: Priority, Action, Direction. The lower the priority number, the higher the priority. Action is either Allow or Deny. Direction is Inbound or Outbound. Always check PAD first when troubleshooting.

## FAQ

**What does NSG stand for?**

NSG stands for Network Security Group. It is a set of security rules in Microsoft Azure that filter network traffic to and from Azure resources.

**Are NSG rules stateful or stateless?**

NSG rules are stateful. This means that if you allow inbound traffic, the outbound response traffic is automatically allowed. You do not need to create a separate outbound rule for the response.

**Can I associate an NSG with more than one subnet?**

Yes, you can associate the same NSG with multiple subnets. However, each subnet can only have one NSG associated. If you need different rules for different subnets, create separate NSGs.

**What is the default priority of an NSG rule?**

When you create a rule, you must specify a priority between 100 and 4096. Lower numbers indicate higher priority. Azure provides default rules with priorities 65000 and 65500 that allow internal virtual network traffic and deny all other inbound traffic.

**How do NSG rules differ from Azure Firewall rules?**

NSG rules are basic, stateful packet filters that are free and operate at the subnet or NIC level. Azure Firewall is a paid, managed service that provides advanced features like application filtering, threat intelligence, and centralized logging. NSGs are simpler, while Azure Firewall is more comprehensive.

**Can I use a domain name in an NSG rule?**

No, NSG rules do not support domain names. You must use IP addresses, CIDR ranges, service tags, or Application Security Groups. If you need to filter by fully qualified domain name (FQDN), use Azure Firewall instead.

**What happens if I have both a subnet-level and NIC-level NSG?**

The subnet-level NSG is evaluated first, followed by the NIC-level NSG. A packet must pass both to reach the destination. So even if the NIC NSG allows traffic, if the subnet NSG denies it, the traffic is blocked.

## Summary

An NSG rule is a fundamental building block of network security in Microsoft Azure. It is a simple but powerful tool that allows you to control inbound and outbound traffic to and from your cloud resources based on source, destination, port, and protocol. The rules are processed in priority order, and the first matching rule determines the action, whether Allow or Deny. NSGs are stateful, so return traffic is automatically handled, reducing rule complexity.

Understanding NSG rules is essential for anyone working with Azure, whether you are a cloud administrator, network engineer, or security professional. In practice, NSGs help you implement the principle of least privilege, segment your network, and meet compliance requirements. They are free to use, making them a cost-effective security measure.

For certification exams like AZ-104, AZ-700, and AZ-500, NSG rules are a recurring topic. You need to know how to configure rules, set priorities, use service tags and Application Security Groups, and troubleshoot connectivity issues. Common mistakes include setting incorrect priorities, forgetting the stateful nature, and misconfiguring subnet vs. NIC associations.

Remember the key takeaway: NSG rules are your first line of defense in Azure networking. Use them wisely, and always follow the principle of least privilege. Properly configured NSGs can prevent unauthorized access and keep your cloud environment secure.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/nsg-rule