Azure network security is easier to understand when three separate questions are kept apart: which traffic is allowed, how administrators reach private virtual machines, and how workloads reach platform services without depending on public endpoints. For the AZ-104 exam, network security groups, Azure Bastion and private endpoints answer those questions at different layers.
Confusing the layers leads to bad designs. An NSG can filter traffic, but it does not create an administrative access service. Bastion provides an access path to VMs, but it is not a general-purpose firewall. A private endpoint gives a PaaS resource a private address in a VNet, but DNS and authorization still have to be correct. Understanding those boundaries is more useful than memorizing feature lists.
NSGs filter traffic at subnet and NIC boundaries
A network security group contains prioritized inbound and outbound rules. Rules match properties such as source, destination, port and protocol, then allow or deny the flow. Lower priority numbers are evaluated first, so a specific rule can take precedence over a later, broader rule.
An NSG can be associated with a subnet, a network interface or both. When both scopes apply, traffic must satisfy the effective rules. This allows broad subnet controls and more specific NIC controls, but it can also make troubleshooting confusing if administrators inspect only one assignment.
For the wider Azure infrastructure certification path, NSGs are a basic segmentation control. They are not a substitute for all firewall capabilities, but they provide efficient stateful filtering close to the workload.
Service tags and application security groups make rules easier to maintain
Hard-coding large IP ranges into every NSG rule creates operational burden. Service tags let Azure-managed address groups represent certain services or platform categories. Application security groups let administrators group VM network interfaces by application role and write rules using those logical groups rather than individual IP addresses.
This makes intent clearer. A rule that allows traffic from a web-tier application security group to an app-tier group on a specific port communicates more than a collection of individual addresses. It also survives many address changes without requiring the rule to be rewritten.
The exam may describe a need to simplify security administration across several VMs. Look for logical grouping and service abstractions before reaching for a long list of host-specific rules.
Effective security rules matter more than one NSG object
A VM can be affected by rules assigned to both its subnet and its network interface. Network Watcher can display effective security rules and simulate traffic. This is valuable because an administrator looking only at the NIC NSG might miss a subnet-level deny, or vice versa.
IP flow verify and NSG diagnostics can show whether a proposed packet is allowed or denied and identify the rule responsible. That turns troubleshooting from guesswork into evidence. If the security result allows the packet, move on to routing, guest firewall and application behavior instead of continuing to edit NSGs.
This disciplined sequence prevents the dangerous habit of adding broad allow rules until connectivity starts working. Connectivity should be restored by identifying the actual control that blocks the intended flow.
Bastion removes the need for public IPs on many admin paths
Azure Bastion provides managed RDP and SSH connectivity to virtual machines using their private IP addresses. Administrators can connect through the Azure portal or supported native-client methods without exposing each target VM directly to the internet with its own public IP.
This reduces the attack surface associated with open management ports. The VM can remain private while the Bastion service provides the access path. The target’s own authentication and authorization still matter; Bastion transports the session but does not eliminate operating-system identity controls.
Bastion also has SKU and feature differences. Native client support and private-only deployment have additional requirements. AZ-104 candidates should focus on the architectural purpose: secure administrative reach to private VMs without making every VM an internet-facing endpoint.
Private-only Bastion changes the exposure model further
A private-only Bastion deployment can remove the public IP from the Bastion resource itself and allow access through private connectivity. That is useful in environments where administrative access must remain on private network paths end to end.
The design requires appropriate upstream connectivity such as VPN or ExpressRoute for administrators outside Azure, and the Bastion subnet still needs the traffic required by the service. Private-only does not mean “no networking requirements.” It means the access architecture is intentionally private rather than internet-facing.
For exam scenarios, distinguish between removing a public IP from the target VM and requiring the Bastion host itself to be private-only. The first is a common benefit of ordinary Bastion. The second is a more specific deployment choice.
Private endpoints bring PaaS access into the VNet
An Azure private endpoint is a network interface with a private IP address from the customer’s virtual network. It connects that address to a supported service through Azure Private Link. Applications can then reach the service through a private endpoint instead of relying on the public service endpoint.
This is valuable for storage, databases and other PaaS services where the workload should use private addressing. The service itself remains managed by Azure; the private endpoint is the network representation that brings access into the VNet.
Private endpoints are often preferred in sensitive production designs because they provide a private IP and can support tighter data-exfiltration controls than older service-endpoint patterns. They also create additional DNS design requirements.
DNS is part of private-endpoint design
Applications normally connect to a service by name. After a private endpoint is introduced, that name must resolve to the private endpoint address for clients that should use the private path. Azure private DNS zones are commonly used to provide that resolution.
A private endpoint can be configured perfectly while the application still connects to the public endpoint because DNS returns the public address. Conversely, a bad private DNS configuration can make the service unreachable even though routing and NSGs look correct. Always include name resolution in private-endpoint troubleshooting.
This is a classic AZ-104 cross-domain issue: networking is not only IP routes and security rules. DNS determines which address the client attempts to reach in the first place.
Private endpoints do not replace authorization
Private network reach does not automatically grant access to the data or service. A storage account reached through a private endpoint still evaluates the caller’s storage authorization. A database still requires database authentication. Network isolation and identity remain separate controls.
This layered design is desirable. If credentials are compromised, network restrictions can still reduce where they can be used. If a workload is on the correct network, identity controls still limit what it can do. Strong security depends on both boundaries.
The broader cloud architecture certification context uses this pattern repeatedly: private connectivity reduces exposure, while least-privilege identity limits authority.
Use the right diagnostic tool for the failing layer
If a VM cannot communicate, start with the intended path. Network Watcher connection troubleshoot can help identify routing, NSG and connectivity problems. IP flow verify can test a particular flow against NSG rules. Effective security rules reveal the combined rule set. DNS tools confirm whether a private service name resolves to the expected address.
If Bastion cannot reach a VM, check the Bastion deployment, peering where applicable, NSGs and the target VM. If a private endpoint is unreachable, check its approval state, private DNS, routing, NSG behavior where applicable and service authorization. Do not solve a DNS problem by widening an NSG.
The site’s Azure administrator role coverage reflects this troubleshooting reality: administrators need enough breadth to identify which Azure layer is actually responsible.
Think of these services as complementary controls
NSGs answer “may this network flow pass?” Bastion answers “how can an administrator reach a private VM safely?” Private endpoints answer “how can this VNet reach a managed service through a private address?” A secure design can legitimately use all three because they protect different parts of the path.
On AZ-104, choose the feature whose purpose matches the requirement, then consider the dependencies around it. That is more reliable than selecting the most security-sounding technology in the list of answers.
NSGs are stateful, and default rules still matter
Azure NSGs are stateful. When a connection is allowed in one direction, return traffic for that established flow does not require a separate mirror rule simply because the packet direction reverses. This reduces the need for duplicate rule pairs and is an important distinction from purely stateless packet filters.
Every NSG also contains default rules. Custom rules with higher priority can override the effective outcome for specific traffic, but administrators should understand what the defaults allow or deny before adding broad exceptions. A common troubleshooting mistake is to assume that because no custom allow rule exists, all traffic must be blocked, or to add an overly permissive rule without checking whether the actual problem is routing or DNS.
Service tags and application security groups help keep custom rules maintainable, but priority and scope still control the result. When both subnet and NIC NSGs apply, the flow must survive both evaluations. Thinking about state, priority and combined scope produces a far more accurate security model than reading one rule in isolation.