Network security groups filter supported inbound and outbound flows using priority, direction, protocol, source\/destination and ports. User-defined routes steer eligible packets to the intended next hop. Application security groups let supported NICs act as logical service tiers inside NSG rules. These do not substitute for one another: an allowed connection may still be unroutable, and a route to a destination does not mean the traffic is authorized.<\/p>\n
To test Microsoft AZ-104<\/a> network controls, draw a two-tier environment: a public web entry point, a private API subnet, and an operator who needs guest access. State allowed web-to-API ports, restricted admin access and prohibited lateral communication. The current Microsoft AZ-104 exam objectives<\/a> explicitly measure NSGs, effective rules, ASGs, UDRs and Azure Bastion.<\/p>\n Each NSG rule has a numeric priority; lower numbers are evaluated ahead of higher numbers within the relevant rule set. Azure also supplies default security rules. A broad early allow may unintentionally permit more than a later deny. NSGs can attach at subnet and network-interface scopes, so the result for a NIC should be inspected through effective security rules rather than guessed from one resource object.<\/p>\n Test an allowed application port and denied direct RDP\/SSH attempt. For each, record source and destination, protocol, effective rule, direction and actual connection outcome. A timeout can reflect routing, firewall or service state; an application-level 403 may show that the network path is open but service authorization was denied. Do not call every failed request an NSG problem.<\/p>\n An application security group identifies a set of supported VM network interfaces for use in rules. It is not a Microsoft Entra group, a role assignment or an authorization token. Membership can make a web-to-API rule easier to manage without manually enumerating every VM private IP, but the underlying NSG is still what filters the traffic.<\/p>\n Place disposable web and API NICs into appropriately named groups and create one narrow permitted application port. Add a second web VM, inspect membership and effective rules, and confirm it receives only the expected relationship. An ASG label does not configure TLS or open the guest OS firewall, so validate the process listening on the target port as well.<\/p>\n Azure automatically provides system routes, with other routes originating from supported peering, BGP and custom tables. A UDR can send matched destinations to a virtual appliance or supported gateway next hop. If the appliance lacks forwarding or the return route is asymmetric, a packet may disappear despite an allowed NSG. More-specific destination prefixes may affect which route matches.<\/p>\n Before routing a spoke network through a hub, draw both request and response paths. VNet peering<\/a> is not transitive by default; gateway transit requires compatible explicit configuration. Compare NIC effective routes before and after a narrow UDR change, and test reachability rather than assuming a route table association is enough.<\/p>\n Azure Bastion supports private RDP\/SSH administration through a managed deployment and compatible configurations. Operators still require suitable Azure resource rights and guest credentials. A visible Bastion resource is not proof its subnet, target access and selected SKU\/features permit the attempted connection. Confirm subnet and regional requirements against Microsoft’s Azure Bastion<\/a> documentation.<\/p>\n Run a disposable guest-access test against a VM without a public IP. If it fails, separate Bastion resource\/network configuration, NSG reachability, Azure role, guest account and VM health. Do not expose management ports to the internet merely to obtain a green connection; that defeats the intended security boundary.<\/p>\n A service endpoint extends the identity of a supported Azure subnet to a supported platform service and routes that service traffic through the Azure backbone. The service does not gain a network interface with a private IP in your virtual network.<\/p>\n After enabling the endpoint on the subnet, configure the target service’s virtual network access rule; enabling the subnet feature by itself does not grant a storage read or SQL query. Microsoft explains the subnet, source-address and routing behavior in its service endpoints documentation<\/a>.<\/p>\n A private endpoint is a private network interface in a chosen VNet that connects through Private Link to a specific supported service resource. The client must resolve the intended service hostname to the appropriate private address, have a valid route to it and still satisfy the target service’s authentication and authorization rules. Private endpoint approval does not automatically configure every corporate DNS resolver or remove every public-access path. Consult the target service’s own network and DNS requirements before restricting public access.<\/p>\n Consider an Azure VM that must read from a restricted storage account. With a service endpoint, enable the supported service endpoint on the VM’s source subnet and allow that subnet in the storage network rules; test the actual client and data-plane identity.<\/p>\n With a private endpoint, create or use the approved endpoint, make the application’s storage hostname resolve to its private IP and verify that the VM or connected on-premises client can route to that IP. A VPN or ExpressRoute connection may support private-endpoint access from on premises when routing and DNS are designed for it; an Azure service endpoint is not an on-premises subnet setting.<\/p>\n When the connection fails, capture DNS output, source IP and subnet, target IP, account networking configuration and service authorization error independently. If the client still resolves the public service address in a private-endpoint design, adding broader storage permissions will not fix the wrong network path. Conversely, correct private DNS does not authorize a missing Blob Data Reader or Writer role. Choose the endpoint model for the required network boundary, then prove both network reachability and data access with separate tests.<\/p>\nEvaluate NSG rules in effective priority order<\/h2>\n
Use ASGs to express application tiers<\/h2>\n
Model UDRs and return traffic<\/h2>\n
Use Bastion rather than broad public management exposure<\/h2>\n
Contrast private endpoints and service endpoints<\/h2>\n