Skip to main content

Technical Lab: Create and configure network security groups (NSGs) and application security groups

Questions​

Question 1 — Multiple Choice​

A security team needs to block all outbound traffic from a set of VMs to the internet, but maintain communication between the VMs themselves on the same subnet. The NSG was associated with the subnet and contains the following outbound rules:

PriorityNamePortProtocolDestinationAction
100Allow-InternalAnyAnyVirtualNetworkAllow
200Deny-InternetAnyAnyInternetDeny
65000AllowVnetOutBoundAnyAnyVirtualNetworkAllow
65001AllowInternetOutBoundAnyAnyInternetAllow

What is the effective behavior for outbound traffic towards the internet?

A) Traffic is allowed because the default rule AllowInternetOutBound has priority over custom rules.

B) Traffic is blocked because the Deny-Internet rule with priority 200 is evaluated before the default rule with priority 65001.

C) Traffic is blocked because the Allow-Internal rule doesn't cover the Internet destination, activating implicit deny.

D) The behavior is undefined because there's a conflict between the custom rule and the default rule for the same destination.

Question 2 — Technical Scenario​

An administrator associated an NSG directly to a VM's NIC (network interface card) and also associated a different NSG to the subnet where this VM is hosted. The VM attempts to receive a TCP connection on port 443.

What is the correct order of inbound rule evaluation and what is the criterion for the connection to be established?

A) The subnet NSG rules are evaluated first; if allowed, the NIC NSG rules are evaluated next. The connection is only established if both NSGs allow the traffic.

B) The NIC NSG rules are evaluated first; if allowed, the subnet NSG rules are evaluated next. The connection is only established if both NSGs allow the traffic.

C) Only the most restrictive NSG between the two is applied, automatically discarding the other.

D) The rules are merged into a single set and Azure evaluates the lowest numerical priority rule among all NSGs.

Question 3 — True or False​

An Application Security Group (ASG) can be used directly as source or destination in an NSG rule even if the ASG member VMs are distributed across different subnets within the same VNet.

True or False?

Question 4 — Technical Scenario​

A company segmented its VMs into three ASGs: asg-web, asg-app, and asg-db. The administrator created the following rule in an NSG associated with the database subnet:

Name:        Allow-App-To-DB
Priority:    300
Source:      asg-app
Destination: asg-db
Port:        1433
Protocol:    TCP
Action:      Allow

During testing, a VM from the asg-web group can connect to the database on port 1433. What is the most likely cause?

A) ASGs don't filter traffic between VMs in the same VNet; the rule only works for external traffic.

B) There exists a rule with lower priority than Allow-App-To-DB allowing traffic from a broader source, like VirtualNetwork, which also covers the VM from asg-web.

C) A NIC can only belong to a single ASG; since the VM from asg-web doesn't have an ASG, it's not filtered by any ASG rule.

D) The NSG was associated with the wrong subnet; to filter with ASG, the NSG must be associated with the destination VMs' NICs, not the subnet.

Question 5 — Multiple Choice​

When creating an NSG rule, an administrator defines the source as 10.0.1.0/24 and the destination as 10.0.2.0/24. Later, the team decides to replace IP addresses with Application Security Groups to simplify maintenance. What technical limitation should be considered in this migration?

A) It's not possible to use ASGs in rules that specify individual ports; they only work with port ranges.

B) An NSG rule cannot mix an ASG as source with an IP range as destination, nor an IP as source with an ASG as destination; source and destination must follow the same specification type when ASGs are involved.

C) ASGs can only be referenced in inbound rules; outbound rules must continue using IP addresses.

D) To use ASGs, the NSG must be associated exclusively with NICs; association with subnets invalidates the use of ASGs in rules.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

In Azure, NSG rules are processed in ascending numerical priority order. The first rule that matches the traffic is applied and processing stops. The Deny-Internet rule (priority 200) is evaluated before the default AllowInternetOutBound rule (priority 65001), therefore blocking occurs.

The conceptual error represented by alternative A is assuming that default rules have precedence over custom rules. The exact opposite occurs: default rules exist precisely to be overridden by rules with lower numerical values. Choosing A would lead an administrator to incorrectly believe that their custom blocks are ignored.

Answer Key — Question 2​

Answer: A

For inbound traffic, Azure first evaluates the NSG associated with the subnet and, if traffic is allowed, then evaluates the NSG associated with the NIC. Both must allow the traffic for the connection to be established. For outbound traffic, the order is reversed: NIC first, then subnet.

Alternative B reverses the order for inbound traffic, which is a common misconception. Alternatives C and D describe behaviors that don't exist in Azure: NSGs are never automatically merged nor is there selection of the most restrictive as a single policy.

Answer Key — Question 3​

Answer: True

An ASG logically groups NICs regardless of the subnet where the VMs are located. The relevant restriction is that all NICs associated with the same ASG must be in the same VNet. There's no requirement that they be in the same subnet.

This behavior is precisely the core value of ASGs: allowing function-based segmentation (web, app, db) without depending on network topology. Confusing VNet scope with subnet scope is a frequent error when evaluating ASG application limits.

Answer Key — Question 4​

Answer: B

ASGs function as a complementary filter within an NSG, but don't replace a complete analysis of all rules present. If there exists a rule with numerically lower priority (for example, priority 100 allowing VirtualNetwork to asg-db on port 1433), it will be evaluated before the Allow-App-To-DB rule and will cover any VM in the VNet, including those from asg-web.

Alternative C contains an incorrect premise: a NIC can belong to multiple ASGs, and VMs without associated ASG simply don't match rules that use ASG as source or destination filter, being evaluated by other available rules. Alternatives A and D describe restrictions that don't exist in the actual behavior of NSGs with ASGs.

Answer Key — Question 5​

Answer: B

When an NSG rule references an ASG, both source and destination must follow the same specification type in the addressing dimension: it's not valid to combine an ASG on one side with an IP address or CIDR prefix on the other. Both sides must be ASGs, or neither should be.

This limitation requires that migration from IPs to ASGs be done completely in each rule, which may require creating intermediate ASGs. Alternatives A, C, and D describe non-existent restrictions: ASGs work with individual ports, in outbound rules, and in NSGs associated with subnets without any problem.