Azure NSGs, Bastion, Service Endpoints & Private Endpoints

A network security group (NSG) is a set of security rules that allow or deny network traffic to and from Azure resources. Each rule is evaluated by a priority number between 100 and 4096, and the key fact is that a lower number means higher priority: Azure processes rules from lowest to highest number and stops at the first match. If a rule at priority 200 allows traffic that a rule at priority 300 would deny, the allow wins because it is evaluated first.

Every rule is defined by a 5-tuple: source, source port, destination, destination port, and protocol (TCP, UDP, ICMP, or Any). Source and destination can be an IP range, a service tag such as Internet or VirtualNetwork, or an application security group. Each rule also carries a direction (inbound or outbound) and an action (Allow or Deny).

Every NSG ships with default rules that you cannot delete but can override with higher-priority custom rules. Inbound defaults allow traffic within the virtual network and from the Azure load balancer, then DenyAllInBound blocks everything else. Outbound defaults allow VNet and internet traffic, then deny the rest. Because of DenyAllInBound, any inbound service you need — RDP, HTTPS, SSH — requires an explicit allow rule.

You can associate an NSG with a subnet, with a network interface (NIC), or with both at once, and understanding the difference is essential for the exam.

An NSG on a subnet applies to every resource in that subnet, which makes it the efficient place to enforce broad rules — for example, blocking inbound RDP from the internet across an entire tier. An NSG on a NIC applies only to that single virtual machine, which is useful when one machine needs an exception the rest of the subnet does not.

When both are present, traffic must pass both NSGs. For inbound traffic to a VM, Azure evaluates the subnet NSG first and then the NIC NSG; for outbound traffic from a VM, it evaluates the NIC NSG first and then the subnet NSG. Because both must allow the flow, the effect is most restrictive wins: if either NSG denies the traffic, it is dropped, even if the other allows it. A common mistake is adding an allow rule to the NIC NSG while a subnet NSG still denies the same traffic — the packet never arrives. Note that NSGs do not apply to traffic between two VMs in the same subnet unless a rule specifically targets it, because the default rules already permit intra-VNet traffic.

Maintaining NSG rules by IP address becomes fragile as soon as machines scale in and out or change addresses. An application security group (ASG) solves this by letting you group virtual machines by role or workload and then reference that group as the source or destination in an NSG rule instead of an IP address. Whenever a question describes wanting to "group VMs and use them in NSG rules instead of IPs," the answer is an application security group.

You create ASGs such as WebServers and DbServers, then assign each VM's network interface to the appropriate ASG. In the NSG you write a rule like "allow TCP 1433 from source ASG WebServers to destination ASG DbServers." When you add a new web server, you simply attach its NIC to the WebServers ASG and it automatically inherits every rule that references that group — no rule editing and no IP bookkeeping.

ASGs make rules readable and self-documenting, and they scale cleanly with virtual machine scale sets. The constraint to remember is that all network interfaces assigned to ASGs used in a single rule, along with the NSG, must belong to the same virtual network. ASGs describe which machines; the NSG still decides what traffic is allowed.

Because NSGs stack at the subnet and NIC levels, and because default rules sit beneath your custom rules, the actual outcome for a given VM can be hard to read from any single rule list. Effective security rules is the feature that resolves this: for a chosen network interface, Azure combines the subnet NSG and the NIC NSG and shows you the single merged set of rules that is really in force.

The processing logic is straightforward once you hold two principles together. Within one NSG, rules are evaluated by priority, lowest number first, and the first match wins — evaluation stops there. Across the two stacked NSGs, traffic must be allowed by both, so a deny in either NSG wins overall. Put simply: first match by priority inside each NSG, most restrictive across the pair.

To view effective rules, open the VM or its network interface, choose Effective security rules under Network settings, or use Network Watcher. This is the definitive way to answer "why is this traffic blocked?" — the view names the exact rule and NSG responsible, so you can see whether a subnet-level DenyAllInBound default or a custom NIC rule is stopping the connection rather than guessing across two rule tables.

Azure Bastion is a fully managed platform service that provides secure RDP and SSH connectivity to your virtual machines directly from the Azure portal over TLS, without giving those VMs a public IP address and without exposing RDP or SSH ports to the internet. Whenever a scenario asks how to "connect to a VM without exposing it to the internet" or "without a public IP," the answer is Azure Bastion.

You deploy Bastion into a dedicated subnet that must be named exactly AzureBastionSubnet, sized at least /26 on the Standard SKU. Bastion itself gets a Standard public IP, but your workload VMs keep only their private IPs. An administrator opens the VM in the portal, clicks Connect, chooses Bastion, and gets an RDP or SSH session rendered in the browser over port 443 — no client software, no jump box to patch, and no inbound 3389 or 22 rule on the VM's NSG.

The security payoff is large: with Bastion in place you can set the VM's NSG to deny all inbound internet traffic, shrinking the attack surface to nothing while administrators still get full console access. Bastion complements NSGs; it does not replace them, and the VM's NSG must still permit RDP or SSH from the AzureBastionSubnet range.

Azure PaaS services such as Azure Storage and Azure SQL Database are reached through a public endpoint by default. Two features secure that access, and the exam frequently asks you to choose between them.

A service endpoint extends your virtual network's identity to the PaaS service over the Azure backbone. Traffic from your subnet to the service stays on the Microsoft network rather than traversing the public internet, and you can then restrict the service's firewall to accept traffic only from that subnet. Crucially, the service keeps its public IP and public endpoint — you are trusting the VNet, not making the service private. Service endpoints are free and quick to enable per subnet and per service type.

A private endpoint goes further: it places a private IP address from your VNet onto the PaaS service through Azure Private Link, so the service is reachable at an address inside your subnet and can be cut off from the public internet entirely. Whenever a question asks how to "give a PaaS service a private IP in the VNet" or wants the most secure, fully private option, the answer is a private endpoint. It usually pairs with a private DNS zone so the service's hostname resolves to the private IP.

Your compliance team sets two rules for a new application tier: administrators must manage the virtual machines without any VM being exposed to the internet, and the application's Azure Storage account must not be reachable over its public endpoint at all. Here is how you deliver both as an administrator.

For administrative access, deploy Azure Bastion into an AzureBastionSubnet. Remove any public IPs from the VMs and set their NSG to DenyAllInBound from the internet while allowing RDP or SSH from the Bastion subnet. Admins now connect through the portal over TLS with no exposed ports — the "connect without a public IP" requirement is met.

For the storage account, create a private endpoint in the application subnet. This assigns the storage account a private IP inside your VNet through Private Link, and you then disable public network access on the account so it answers only on that private IP. Add or link a private DNS zone so the storage account's hostname resolves to the private endpoint's address for the VMs. The result is an application tier with no internet-facing VMs and a storage account that is only reachable privately — exactly the posture the compliance rules require, built entirely from NSGs, Bastion, and a private endpoint.