Virtual Networking
The VNet is the foundation; everything else in this domain is connectivity, then security, then name-resolution and distribution layered on top of it
An Azure virtual network (VNet) is a logically isolated private IP space you define by one or more CIDR ranges, scoped to a single region and subscription but automatically spanning every availability zone in that region. Read this domain as three layers stacked on that foundation, which is also the order the three subtopics follow. First connectivity: you carve the VNet into subnets (Azure reserves five addresses per subnet, so a /24 yields 251 usable hosts), join VNets with peering, and steer packets with system routes and user-defined routes. Second security: you filter that connectivity with network security groups, application security groups, Azure Bastion, and service or private endpoints. Third name-resolution and distribution: Azure DNS answers "what IP?" and a load balancer answers "which backend?". A request usually touches all three (DNS resolves a name to a load balancer's frontend IP, a security layer permits the flow, and routing carries it) but the exam tests each layer as a separate skill.
Network security is layered and additive: each control narrows what the layer below permits, and none of them grants reachability on its own
Think of every security control here as a ceiling on the connectivity the VNet already provides: adding one can only subtract reachability, never create it. A network security group (NSG) is a stateful, priority-ordered allow/deny list matched on the 5-tuple (source, source port, destination, destination port, protocol); when both a subnet NSG and a NIC NSG apply, traffic must pass BOTH, so the effective rule is their intersection and the more restrictive layer wins. An application security group (ASG) is just a role-based handle ("web tier", "db tier") you reference in NSG rules instead of brittle IP ranges. Azure Bastion removes the exposed-management-port surface by brokering RDP/SSH over TLS so VMs need no public IP. Service and private endpoints pull PaaS traffic off the public internet. Because NSGs match only the 5-tuple, none of them inspects application-layer content: that job belongs to Application Gateway or Azure Firewall, which sit outside this domain's filtering controls.
Connectivity, security, and distribution each have a small menu of constructs, and exam questions hinge on picking the right one from the menu
The domain is mostly a set of "which construct when" decisions across three menus. Connectivity: peering joins two VNets over the Microsoft backbone but is non-transitive, so a hub-and-spoke topology needs a network virtual appliance plus user-defined routes (or Virtual Network Manager / Virtual WAN) for spoke-to-spoke transit; one peering can share the hub's VPN/ExpressRoute gateway via Allow gateway transit on the hub and Use remote gateways on the spoke. Security: a service endpoint extends your subnet's identity to a PaaS service that keeps its public IP (no cost, no DNS change, in-VNet only), while a private endpoint projects that resource into your subnet as a private IP via Private Link (reachable from on-premises, needs DNS to map the name to the private IP). Distribution: Azure Load Balancer is Layer 4 (routes on the 5-tuple, one region), Application Gateway is Layer 7 (HTTP path/host routing, one region), Traffic Manager steers at the DNS layer across regions, and Front Door steers at the HTTP edge across regions. Mapping the scenario's verbatim cue ("multiple regions", "URL path", "no public IP", "on-premises") to the right menu item is the whole game.
Standard is now the only forward-looking SKU for public IPs and load balancers, and that changes the secure-by-default behavior you must account for
The Basic SKU was retired on 30 September 2025 for both public IP addresses and Azure Load Balancer, so every new design uses Standard, and Standard's defaults differ from the open-by-default Basic world many older questions describe. A Standard public IP is always statically allocated (the address never changes on stop/start) and is closed to inbound traffic until an NSG rule explicitly allows it. A Standard Load Balancer is likewise zone-redundant and secure-by-default, carries a 99.99% SLA, and provides NO implicit outbound internet connectivity to its backends: outbound must be made explicit (for example via a NAT gateway), and SNAT exhaustion comes from too many concurrent outbound flows, not inbound load. The SKU choice is effectively permanent: there is no in-place Basic-to-Standard upgrade, you migrate by rebuilding, so treat Standard as the answer unless a question explicitly constrains you to Basic.
Which connectivity / distribution construct to reach for
| Construct | OSI layer / mechanism | Scope | Decides on | Reach for when |
|---|---|---|---|---|
| Azure Load Balancer | Layer 4 (transport) | Single region | 5-tuple hash | Spread TCP/UDP flows across backends in one region |
| Application Gateway | Layer 7 (HTTP) | Single region | URL path / host header | Content-based HTTP(S) routing within one region |
| Traffic Manager | DNS layer | Global / multi-region | DNS response (routing method) | Steer users to a region at name-resolution time |
| Azure Front Door | HTTP edge | Global / multi-region | HTTP request at the edge | Global HTTP(S) acceleration and edge routing |
| VNet peering | Backbone (private IP) | Same or cross-region | Private IP, non-transitive | Connect two VNets directly over the Microsoft backbone |