Memory hook: Check the effective route and the effective rule in both directions.
Must remember
- VNets contain address spaces and subnets. Plan non-overlapping ranges and future growth; supported peering requires compatible addresses. Peering connects VNets but is not automatically transitive through a third VNet.
- Azure selects routes using prefix specificity and route-source precedence for equal prefixes; inspect effective routes when system, BGP and user-defined routes interact. A UDR can direct traffic to a virtual appliance, but the appliance must forward it and the return path must work.
- For ordinary equal-prefix comparisons, remember UDR → BGP → system; first compare the destination prefix length. A matching
/24normally beats a/16regardless of that general source order. Service-specific routes have exceptions: service-endpoint routes cannot simply be overridden by a UDR. Inspect the effective route rather than treating the mnemonic as universal. - Azure reserves the first four and last IPv4 addresses of each subnet. A
/27contains 32 addresses, leaving 27 usable; service-specific subnet sizing can require more than the generic minimum. Subnet capacity planning must include service reservations and scale-out needs. - NSGs are stateful network filtering with priority-ordered allow/deny rules. They can apply at subnet and NIC scopes; evaluate the effective combination. Application security groups group supported VM interfaces for rule targeting; they are not application-layer WAFs.
- Public IP addresses have SKU/allocation/zone properties. NAT Gateway supports explicit outbound SNAT for associated subnets; consider port use and destination patterns. Do not assume new workloads receive default outbound internet access.
- Bastion provides managed administration through supported private VM access without exposing a public management port on each VM. It still needs the required deployment/network configuration and authorised users.
- Service endpoints extend supported service access from a VNet using its public service endpoint and service-side rules. Private endpoints use a private IP for a specific resource/subresource; DNS must resolve appropriately. Endpoint creation and resource approval are separate checks.
- Diagnose with Network Watcher tools, Connection Monitor, effective security rules/routes, name resolution and application listener checks. Existing stateful flows may not behave like brand-new test connections after a rule change.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| One private PaaS resource endpoint | Private Link/private endpoint with private DNS. |
| Traffic must traverse a network appliance | UDR plus forwarding and a symmetric return path. |
| VM administration without a VM public IP | Bastion where appropriate. |
Traps
- Peering is not automatically transitive.
- A service endpoint does not put the service itself inside your subnet.
- An NSG allow does not create a route.
Active recall
1. Why inspect both subnet and NIC NSGs?
Both can affect effective traffic permission.
2. What is missing if a UDR points to an appliance that does not forward?
A functioning forwarding path; the route alone cannot deliver traffic.
3. Why can private endpoint traffic still resolve publicly?
The client may lack the correct private DNS zone link or forwarding path.
4. Does a connected VNet automatically access every PaaS resource?
No. Network rules and data authorisation remain separate.
5. What should replace assumptions about outbound access?
An explicit, supported egress design and verification from the workload.