ScenarioCert
Sign inStart free test
AZ-700 ยท Design and implement Azure network security services (15-20%)

Implement and manage network security groups

Practice questions and explanations for the "Implement and manage network security groups" objective of the Designing and Implementing Microsoft Azure Networking Solutions exam. Skills measured as of 2026-07-27.

Skills in this objective

  • Create a network security group (NSG)
  • Associate a NSG to a subnet or network interface
  • Create an application security group (ASG)
  • Associate an ASG to a network interface
  • Create and configure NSG inbound and outbound security rules
  • Implement virtual network flow logs
  • Interpret virtual network flow logs
  • Verify IP flow
  • Configure an NSG for remote server administration, including Azure Bastion
  • Implement and manage virtual network security by using Azure Virtual Network Manager

Test yourself on this domain

Take the free 15-question test, or unlock all 150 questions and practice this domain on its own.

Free testUnlock for $29

Sample questions

4 of the 11 questions we have for this objective, shown with the answer and the reasoning.

Implement and manage network security groups

Tarrant Biosciences has an application security group named asg-api that already contains the network interfaces of four VMs in a virtual network named vnet-east (10.10.0.0/16) in East US. A new API server named vm-api5 was deployed into a virtual network named vnet-west (10.30.0.0/16) in West US. An administrator tries to add the network interface of vm-api5 to asg-api so that an existing NSG rule allowing TCP 443 to asg-api covers the new server, but the operation fails.

Why does the operation fail?

  1. AAll network interfaces in an ASG must exist in the same virtual network as the first network interface that was added to the ASG.An ASG is scoped to one virtual network. Once the first NIC is assigned, every subsequent NIC must belong to the same virtual network, so a NIC in vnet-west cannot join asg-api.
  2. BAn ASG can contain at most four network interfaces, so asg-api is full.There is no limit of four NICs per ASG. The limits are far higher (thousands of IP configurations per ASG), so capacity is not the issue.
  3. CThe network interface of vm-api5 must first be associated with the same NSG that references asg-api.ASG membership is independent of NSG association. A NIC does not need any NSG attached to be a member of an ASG.
  4. DASGs can only contain network interfaces from virtual networks in a different region when global peering is enabled between the two virtual networks.Peering has no bearing on ASG membership. The restriction is to a single virtual network, not to peered or cross-region networks.
Why: Application security groups have a strict scoping rule: all network interfaces assigned to an ASG must be in the same virtual network as the first network interface assigned to it. A related rule is that when an NSG rule specifies an ASG as both source and destination, both ASGs must exist in the same virtual network. The deciding fact in the scenario is that vm-api5 lives in vnet-west while the existing members live in vnet-east. The fix is to create a separate ASG in vnet-west (and an NSG rule there) or to deploy the new server into vnet-east. The distractors cite limits and peering behaviors that do not exist for ASGs.
Implement and manage network security groups

Dunmore Logistics has a VM named vm-sql1 (10.90.2.8) in a subnet associated with an NSG that has 30 custom rules. The virtual network is also in a network group that receives security admin rules from Azure Virtual Network Manager. An application server at 10.90.6.20 cannot connect to vm-sql1 on TCP 1433. The engineer needs to identify, as quickly as possible, which specific rule is allowing or denying this one flow.

Which Network Watcher capability should the engineer use?

  1. AIP flow verify, specifying vm-sql1, inbound direction, TCP, local 10.90.2.8:1433 and remote 10.90.6.20.IP flow verify evaluates a single 5-tuple against the effective NSG rules and Virtual Network Manager security admin rules and returns the name of the rule that allowed or denied it.
  2. BPacket capture on vm-sql1 filtered to TCP 1433, then inspect the capture for RST segments.A packet capture shows what reaches the VM but does not tell you which NSG or admin rule made the decision, and it requires the Network Watcher agent extension.
  3. CNext hop, specifying vm-sql1 as the source and 10.90.6.20 as the destination.Next hop answers routing questions, such as whether traffic goes to a virtual appliance or the internet. It does not evaluate security rules.
  4. DConnection troubleshoot from vm-sql1 to 10.90.6.20 on TCP 1433.Connection troubleshoot tests the reverse direction here and reports reachability hop by hop; it is a broader tool than needed when the question is which rule decided a specific inbound flow.
Why: IP flow verify is the targeted tool for the question of whether a specific packet would be allowed or denied at a VM network interface and which rule made the decision. You provide the VM, the network interface, direction, protocol, local and remote IP addresses and ports, and the result returns Allow or Deny together with the name of the matching NSG rule or Virtual Network Manager security admin rule. The deciding constraints are speed and the need for a rule name, which the other diagnostics do not provide: next hop is for routing, packet capture shows traffic but not decisions, and connection troubleshoot performs a broader end-to-end test. NSG diagnostics is a related tool that returns every rule evaluated for a flow when you need the full picture.
Implement and manage network security groups

Orinda Payments has a subnet named snet-backend (10.80.5.0/24) associated with an NSG named nsg-backend. The VMs in the subnet must be able to reach Azure Storage accounts in the same region over TCP 443 and must be blocked from reaching any other internet destination. The security policy requires least privilege, and the solution must keep working when Microsoft adds new IP ranges for Azure Storage.

Which outbound rules should you add to nsg-backend?

  1. APriority 100: Allow TCP 443 to the Storage service tag. Priority 110: Deny any protocol and any port to the Internet service tag.The Storage service tag is maintained by Microsoft and tracks the Storage address ranges automatically. The deny rule at 110 blocks everything else bound for the internet while the lower-numbered allow rule still permits storage traffic.
  2. BPriority 100: Deny any protocol and any port to the Internet service tag. Priority 110: Allow TCP 443 to the Storage service tag.Rules are processed from the lowest number up and processing stops at the first match. Storage IPs are part of the Internet tag, so the deny at 100 matches first and the allow at 110 is never reached.
  3. CPriority 100: Allow TCP 443 to the current list of Azure Storage IP ranges for the region. Priority 110: Deny any protocol and any port to 0.0.0.0/0.Hard-coding IP ranges breaks when Microsoft adds new ranges, which the scenario explicitly rules out. A service tag removes that maintenance burden.
  4. DPriority 4096: Allow TCP 443 to the Storage service tag and rely on the default DenyAllOutBound rule to block the rest.The default AllowInternetOutBound rule at 65001 would still allow all other internet traffic, because 65001 is reached before DenyAllOutBound at 65500. An explicit deny is required.
Why: NSG rules are evaluated by priority, lowest number first, and the first matching rule ends the evaluation. To allow one Azure service while blocking general internet egress, the allow rule must have a lower number than the deny rule, and the deny must explicitly target the Internet service tag because the default AllowInternetOutBound rule at 65001 would otherwise permit the traffic. Service tags such as Storage (or the regional variant Storage.EastUS2) are updated by Microsoft as address ranges change, which satisfies the requirement that the rule keep working without maintenance. Option B is the classic ordering trap, and option D forgets that the default rules allow outbound internet traffic.
Implement and manage network security groups

Fennimore Partners deploys Azure Bastion (Standard SKU) into a subnet named AzureBastionSubnet (10.100.0.0/26) in a virtual network named vnet-hub. Company policy states that administrators may reach Linux VMs in a peered spoke subnet named snet-linux (10.101.1.0/24) only through Bastion; no public IP addresses are allowed on the VMs. The security team has created an NSG named nsg-bastion for AzureBastionSubnet that contains only the default rules, and an NSG named nsg-linux for snet-linux that contains the default rules plus a priority 4000 inbound rule that denies all traffic from any source, added to enforce the Bastion-only policy. Bastion sessions are currently failing to connect.

Which three inbound rules should you add? Each correct answer presents part of the solution.

  1. AIn nsg-bastion, priority 100: Allow TCP 443 from the Internet service tag.Administrators reach the Bastion host over HTTPS from the Azure portal or native client, so AzureBastionSubnet must accept TCP 443 from the internet.
  2. BIn nsg-bastion, priority 110: Allow TCP 443 from the GatewayManager service tag.The Bastion control plane uses the GatewayManager service tag to manage the instances over TCP 443; without this rule Bastion cannot be provisioned or operate correctly.
  3. CIn nsg-linux, priority 100: Allow TCP 22 from 10.100.0.0/26.Bastion opens the SSH session to the target VM from its own subnet, so the target subnet must allow TCP 22 from the AzureBastionSubnet prefix. Here the priority 4000 deny in nsg-linux sits above the default AllowVnetInBound rule, so an explicit allow at a lower number is required.
  4. DIn nsg-linux, priority 100: Allow TCP 22 from the Internet service tag.Opening SSH from the internet defeats the purpose of Bastion and violates the Bastion-only policy. SSH must come only from the Bastion subnet.
  5. EIn nsg-bastion, priority 120: Allow TCP 22 from the Internet service tag.The Bastion host itself is never accessed over SSH. The required inbound ports on AzureBastionSubnet are 443 (Internet, GatewayManager, AzureLoadBalancer) and 8080/5701 from VirtualNetwork for data-plane communication.
Why: Azure Bastion has a documented set of NSG requirements when you choose to protect AzureBastionSubnet with an NSG. Inbound, the subnet must allow TCP 443 from the Internet tag (user sessions), TCP 443 from the GatewayManager tag (control plane), TCP 443 from the AzureLoadBalancer tag (health probes), and TCP 8080 and 5701 from the VirtualNetwork tag (data-plane communication between Bastion instances). Outbound, it needs TCP 22 and 3389 to the target VM subnets (or VirtualNetwork), TCP 443 to AzureCloud, 8080 and 5701 to VirtualNetwork and TCP 80 to Internet. With only the default rules, nsg-bastion already allows the AzureLoadBalancer and VirtualNetwork flows, so the two missing pieces are 443 from Internet and 443 from GatewayManager. On the target VM side, the default AllowVnetInBound rule would normally cover SSH from the peered Bastion subnet because the VirtualNetwork tag includes peered virtual networks, but the custom deny at priority 4000 overrides it, so SSH must be allowed explicitly and scoped to the AzureBastionSubnet prefix to keep the Bastion-only guarantee. Options D and E are the traps: they open management ports to the internet, which Bastion exists to avoid.

Written from the public documentation. Not affiliated with Microsoft. Official study guide.