Learn NSGs, ASGs, Bastion, service endpoints, private endpoints, and the DNS implications that matter on AZ-104.
This is one of the highest-value AZ-104 networking areas because it combines security, reachability, and troubleshooting. Candidates often know the names of NSGs, service endpoints, and private endpoints, but they miss the operational consequence of choosing the wrong one.
Microsoft specifically includes NSGs and ASGs, effective security rules, Azure Bastion, service endpoints for Azure PaaS, and private endpoints for Azure PaaS. Those are all ways to influence how access is allowed, denied, or routed without necessarily changing the application itself.
NSGs and ASGs shape packet filtering inside Azure networks. Bastion gives administrative access to VMs without exposing those VMs directly to the internet. Service endpoints extend VNet identity to a platform service while the service still has a public endpoint. Private endpoints place a private IP inside your VNet for the service and usually become the stronger isolation pattern when data-plane privacy matters most.
Private endpoints nearly always carry a name-resolution requirement. If the private DNS record or zone link is wrong, the connectivity test often looks like a storage, database, or firewall issue even when the real problem is DNS.
| Need | Strongest first fit | Why |
|---|---|---|
| Filter traffic at subnet or NIC scope | NSG | It is the core packet-filtering control |
| Reuse workload groups inside NSG rules | ASG | Reduces rule sprawl by grouping NICs logically |
| Administer a VM without putting a public IP on it | Bastion | Provides controlled browser-based access path |
| Restrict PaaS access from a VNet while the service still has a public endpoint | Service endpoint | Lightweight network identity extension |
| Reach a PaaS service through a private IP in the VNet | Private endpoint | Stronger private-access design for data-plane traffic |
| Question | Service endpoint | Private endpoint |
|---|---|---|
| Does the service keep a public endpoint? | Yes | No for the intended private path |
| Does the VNet get a private IP for the service? | No | Yes |
| Is private DNS usually part of the design? | Less often | Very often |
| Typical exam use | Restrict access from trusted VNets with lighter setup | Stronger private data-plane isolation |
This is the most important network-path distinction in the AZ-104 storage and networking objectives.
flowchart LR
W["Workload in VNet"] --> SE["Service endpoint path"]
SE --> PUB["Azure PaaS public endpoint"]
W --> PE["Private endpoint in subnet"]
PE --> PRIV["Azure PaaS service over Private Link"]
DNS["Private DNS zone"] -.maps service name to private IP.-> PE
The key thing to notice is that a private endpoint changes the address the workload should resolve and target. A service endpoint does not. That is why private endpoint problems often show up first as DNS problems.
AZ-104 includes effective security rules because a configured NSG rule is not always the whole story. Traffic may be affected by multiple rules, multiple scopes, and the actual source or destination path in the network. When the portal or the exam says “effective,” read that as “what really wins after Azure evaluates the stacked controls.”
This is a compact example of the NSG and ASG relationship that AZ-104 expects you to understand.
1# Create an application security group for web servers
2az network asg create -g RG -n web-asg
3
4# Create an NSG and allow HTTPS traffic to the ASG
5az network nsg create -g RG -n web-nsg
6az network nsg rule create -g RG --nsg-name web-nsg -n allow-https \
7 --priority 100 --direction Inbound --access Allow --protocol Tcp \
8 --source-address-prefixes Internet --destination-asgs web-asg --destination-port-ranges 443
What matters is not memorizing the flags. It is recognizing the model:
After this page, move to Azure DNS and Load Balancing.