Skip to main content

Technical Lab: Create a network security group (NSG)

Questions​

Question 1 — Multiple Choice​

An infrastructure team needs to ensure that virtual machines in a specific subnet do not receive inbound traffic on port 3389 (RDP) from the internet, but can still communicate freely with each other within the same virtual network.

What is the correct approach when creating a deny rule in the NSG associated with the subnet?

A) Create an inbound rule with priority 100, source Internet, destination port 3389, action Deny, and leave internal communication without an explicit rule.

B) Create an inbound rule with priority 100, source Internet, destination port 3389, action Deny, and create an inbound rule with priority 200, source VirtualNetwork, destination port 3389, action Allow.

C) Create an outbound rule with priority 100, destination Internet, destination port 3389, action Deny.

D) Create an inbound rule with priority 4096, source Internet, destination port 3389, action Deny.

Question 2 — Technical Scenario​

An administrator associates an NSG to a VM's network interface (NIC) and also associates a different NSG to the subnet where this VM is connected. The VM needs to receive HTTP traffic (port 80) from an external IP address.

The subnet NSG has the following inbound rule:

Priority: 200 | Source: * | Destination port: 80 | Action: Allow

The NIC NSG has the following inbound rule:

Priority: 100 | Source: * | Destination port: 80 | Action: Deny

After configuration, HTTP traffic does not reach the VM. What is the correct cause?

A) The subnet NSG takes precedence over the NIC NSG for inbound traffic, and its deny rule blocks the traffic.

B) For inbound traffic, the subnet NSG is evaluated first; since it allows traffic, evaluation ends there and traffic should pass.

C) For inbound traffic, the subnet NSG is evaluated first and allows traffic, but the NIC NSG is evaluated next and denies traffic before it reaches the VM.

D) NSGs associated with NICs and subnets cannot coexist; the configuration is invalid and traffic is blocked by default.

Question 3 — True or False​

An NSG can be associated simultaneously with multiple subnets and multiple network interfaces, and any changes to its rules are applied immediately to all associated resources, without requiring reassignment.

Question 4 — Technical Scenario​

A developer reports that a VM is successfully making outbound calls to the internet on port 443, even without any explicit outbound rule configured in the NSG associated with its NIC. The security team questions whether the NSG is functioning correctly.

What is the correct technical explanation for this behavior?

A) The NSG is ignoring outbound rules because no inbound rules were configured, making all outbound traffic allowed as a fallback.

B) The NSG has non-editable default rules that allow all outbound traffic to the internet, and these rules have lower priority than any custom rule, but are applied in the absence of explicit rules.

C) This behavior indicates that the NSG is not correctly associated with the NIC, as outbound traffic would always be blocked without an explicit rule.

D) NSGs do not control outbound traffic by default; this function is exclusive to Azure Firewall.

Question 5 — Multiple Choice​

When creating an NSG in the Azure portal, an engineer observes that default rules include a rule called DenyAllInbound with priority 65500. Another colleague suggests creating a custom deny rule with priority 65000 to block all unauthorized inbound traffic, arguing that this reinforces security.

Which statement correctly describes the impact of this decision?

A) The custom rule with priority 65000 is redundant, as the default rule DenyAllInbound with priority 65500 already ensures blocking of all traffic not permitted by previous rules.

B) The custom rule with priority 65000 is necessary because default rules can be removed by the administrator, and the custom rule ensures the blocking persists.

C) The custom rule with priority 65000 will take precedence over the default rule 65500 and will block traffic even before allow rules with priority higher than 65000.

D) Creating a rule with priority 65000 will cause conflict with default rules and result in a validation error in Azure.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • The rule with source Internet and action Deny on port 3389 correctly blocks external RDP access. However, the VirtualNetwork service tag already includes the virtual network address space, including internal communication. Without an explicit Allow rule for VirtualNetwork, the deny rule for Internet would not block internal traffic by itself, but option B demonstrates correct reasoning by explicitly ensuring internal communication is preserved with a lower priority rule.
  • Option A seems reasonable but doesn't demonstrate awareness that in environments with multiple NSGs or future changes, the absence of explicit allow rules can be problematic. Option C confuses direction (outbound vs. inbound) for the proposed objective. Option D uses priority 4096, which is outside the valid range (100 to 4096 is valid, but in subnet NSG context, values close to maximum are processed last and may be preceded by other rules, making the deny ineffective if there are previous allow rules).
  • The consequence of choosing option D would be that any existing allow rule with priority lower than 4096 would take precedence, making the deny rule inoperative in practice.

Answer Key — Question 2​

Answer: C

Explanation:

  • For inbound traffic, Azure evaluates the subnet NSG first and then the NIC NSG. Both need to allow traffic for it to reach the VM. In the described scenario, the subnet NSG allows (priority 200, Allow), but the NIC NSG denies (priority 100, Deny). Traffic is blocked by the NIC NSG before reaching the VM's operating system.
  • Option A reverses the precedence order, incorrectly suggesting that the subnet NSG dominates the outcome. Option B describes the correct evaluation order but erroneously concludes that processing ends at the first Allow. Option D is false: NSGs on NIC and subnet can coexist and it's a common practice.
  • The central conceptual error in the distractors is treating NSG evaluation as short-circuiting at the first Allow, when in reality both NSGs need to allow traffic for it to flow.

Answer Key — Question 3​

Answer: True

Explanation:

  • An NSG is an independent resource that can be associated with zero or more subnets and zero or more NICs simultaneously. When its rules are modified, Azure applies the changes to all associated resources immediately and consistently, without requiring reassignment or resource reinitialization.
  • This behavior is operationally relevant: a single rule change in a shared NSG can impact dozens of VMs simultaneously. It's a critical planning point in production environments, as an incorrect rule applied to a widely shared NSG has reach proportional to the number of existing associations.

Answer Key — Question 4​

Answer: B

Explanation:

  • Every NSG in Azure is created with a set of non-removable default rules. Among them is the rule AllowInternetOutbound (priority 65001), which allows all outbound traffic destined for the Internet service tag. Having lower priority than any custom rule (minimum 100), it's only applied when no custom rule overrides it, but it's always present.
  • Option A describes non-existent behavior: there's no dependency relationship between inbound and outbound rules. Option C suggests the NSG isn't associated, but the described behavior is exactly what's expected for a correctly functioning NSG without custom outbound rules. Option D is incorrect: NSGs control both inbound and outbound traffic; Azure Firewall is a complementary solution, not a substitute for this basic control.

Answer Key — Question 5​

Answer: A

Explanation:

  • Default rules in an NSG, including DenyAllInbound (priority 65500), cannot be removed. They are automatically inserted by Azure and are always present. Therefore, a custom deny rule with priority 65000 would be redundant: any traffic that reached priority 65000 without being allowed by a previous rule would also be denied by the default rule 65500.
  • Option B is based on a false premise: default rules are immutable and cannot be deleted. Option C describes a real consequence of how priorities work, but isn't the correct impact of the decision in the question's context, as a rule with priority 65000 would only be reached if there were no custom rules with lower priority covering it. Option D is false: there's no validation conflict when using priorities close to default rules.
  • The central learning point is that default rules exist precisely to ensure safe fallback behavior, and understanding their immutability is fundamental to designing NSGs without unnecessary redundancies.