Section 8 of 14
Networking is where most candidates lose marks. The concepts are not individually complex, but Microsoft loves to test the specific distinctions: Layer 4 vs Layer 7, Service Endpoint vs Private Endpoint, VNet Peering vs ExpressRoute, basic load balancer vs standard. Read every question's keywords carefully.
A VNet is your private network in Azure. Resources inside it can talk to each other privately. A VNet is bound to ONE region and ONE subscription.
VNets are defined by one or more IPv4 (and optional IPv6) CIDR ranges
Subnets are subsets of the VNet's address space
Subnets are regional - they can span availability zones within the region
Resources do not actually 'live in' a subnet - their NIC is attached to a subnet, which has a private IP from the subnet's range
Azure reserves 5 IPs per subnet - always .0 = network address (always reserved) .1 = default gateway .2 and .3 = Azure DNS .255 (or the last IP) = broadcast A /24 subnet = 256 total - 5 reserved = 251 usable. The exam tests this calculation. Always subtract 5.
Provide logical divisions within a virtual network
Improve security and performance management through segmentation
Cannot overlap with other subnets in the same VNet
Cannot be nested - they are flat divisions
Cannot be resized in some peering scenarios without removing the peering first
| Type | Description |
|---|---|
| Private IP | Used within a VNet or hybrid network connections (RFC 1918 ranges typically) |
| Public IP | Internet-facing - assigned to resources that need to receive traffic from the internet |
| Static IP | Manually selected, remains fixed within subnet's range |
| Dynamic IP | Automatically assigned by Azure from available addresses, may change |
| SKU | Notes |
|---|
| Standard | Always static, supports availability zones, secure by default, REQUIRED for Standard Load Balancer |
| Basic | Being retired Sept 2025. Can be dynamic. Cannot be used with Standard Load Balancer |
Standard Load Balancer requires Standard Public IP. Basic LB requires Basic Public IP. SKUs must match. If a question shows a Standard LB and asks which Public IP works, only Standard qualifies.
VNet Peering connects two VNets over the Microsoft backbone. No public internet, low latency, high bandwidth. It is the standard way to connect Azure VNets.
Regional Peering - within the same Azure region
Global Peering - across Azure regions (cross-region VNet peering)
Peering must be configured in BOTH directions (A to B AND B to A)
Peered VNets CANNOT have overlapping IP ranges
VNet Peering is NON-TRANSITIVE If A is peered to B, and B is peered to C, A and C CANNOT communicate. Workaround: peer A directly to C, OR use a hub-and-spoke design where the hub forwards traffic via an NVA or Azure Firewall. Azure does NOT auto-NAT overlapping address spaces. If IPs overlap, peering fails entirely.
In a hub-and-spoke topology, the hub VNet has the VPN/ExpressRoute gateway. Spokes can use that gateway instead of each spoke having its own.
| Where to enable | Setting |
|---|---|
| On the hub side of the peering | Allow Gateway Transit |
| On the spoke side of the peering | Use Remote Gateway |
Both settings must be enabled (one on the hub side, one on the spoke side). They work as a pair. If only one is enabled, the spoke cannot use the hub's gateway.
| Feature | Description |
|---|---|
| System Routes | Default Azure-created routes - handles traffic within VNets, across subnets, to internet |
| User-Defined Routes (UDRs) | Custom rules that override system routes - 'for this CIDR, next hop is this NVA' |
| Service Chaining | Direct traffic through an NVA/firewall via UDRs - e.g. spoke-to-spoke through a hub firewall |
NSGs are stateful firewall rules attached to subnets or NICs. They filter traffic based on source, destination, port, protocol, and direction.
Priority (100-4096)
Name
Source (IP, service tag, or Application Security Group)
Source port range
Destination (IP, service tag, or ASG)
Destination port range
Protocol (TCP, UDP, ICMP, Any)
Action (Allow or Deny)
Lower priority number = HIGHER priority (processed first) A rule with priority 100 is processed BEFORE a rule with priority 200. Once a rule matches, processing stops - subsequent rules with the same attributes are NOT processed. Default rules (65000-65535 range) allow VNet-to-VNet traffic, Azure Load Balancer probes, and deny all else. They cannot be deleted but can be overridden by higher-priority custom rules.
If you allow inbound traffic on a port, the return outbound response is automatically allowed. You do not need separate outbound rules for return traffic. NSG rules are direction-specific (inbound or outbound) but stateful within that direction.
Service tags represent Azure services (Internet, AzureLoadBalancer, Storage, Sql, etc.). Use them in NSG rules instead of trying to maintain lists of Azure service IPs (which change frequently).
ASGs are tags you attach to a VM's NIC. You then reference the ASG in NSG rules instead of individual IPs.
Use ASGs to logically group VMs by role Instead of writing NSG rules that reference specific IPs, tag each VM's NIC with an ASG like 'web-tier' or 'db-tier'. Then write rules like 'web-tier can talk to db-tier on port 1433'. As VMs come and go, you do not need to update NSG rules - just tag the NICs.
Use Network Watcher IP Flow Verify to test if a packet would be allowed/denied
Use NSG Flow Logs to see actual traffic patterns and rule matches
Use Effective Security Rules on a NIC to see all rules applied (including subnet-level NSGs)
Azure offers multiple load balancing services. Picking the right one comes down to OSI layer and scope (regional vs global).
| Service | OSI Layer | Protocols | Scope | Notes |
|---|---|---|---|---|
| Azure Load Balancer | Layer 4 | TCP/UDP | Regional | No SSL termination, no WAF |
| Application Gateway | Layer 7 | HTTP/HTTPS | Regional | SSL offload, WAF, URL routing |
| Azure Front Door | Layer 7 | HTTP/HTTPS | Global | CDN, SSL offload, WAF, anycast |
| Azure Traffic Manager | DNS-based | Any (just DNS) | Global | DNS resolution only, no traffic inspection |
Layer 4 vs Layer 7 - the most-tested distinction If the question mentions 'route based on URL path' or 'redirect /api to a different backend' or 'SSL termination', the answer is Application Gateway (Layer 7). If the question is 'just distribute TCP traffic across VMs', the answer is Azure Load Balancer (Layer 4).
Web Application Firewall (WAF) is ONLY available on Application Gateway and Azure Front Door. NOT on the basic Azure Load Balancer. If a question asks about protecting a web app from OWASP threats, the answer involves App Gateway or Front Door, never Azure LB.
| SKU | Notes |
|---|---|
| Basic | Being retired Sept 2025. No SLA. Same VNet only. Backed by NICs only. |
| Standard | 99.99% SLA, supports availability zones, more flexible backends (NICs or IP addresses), required for production |
| Type | Use case |
|---|---|
| Public Load Balancer | Internet-facing apps - patient portal, public website, etc. |
| Internal Load Balancer (ILB) | Internal apps within VNet - line-of-business apps, multi-tier internal applications, cross-premises traffic via VPN |
Internal Load Balancer scenarios: LOB apps within the VNet, multi-tier applications inside a VNet, cross-premises traffic via VPN. NOT for internet-facing web applications - that requires a Public Load Balancer.
Frontend IP - the entry point (public or private)
Backend Pool - the target VMs/instances
Health Probe - checks which backend instances are healthy
Load Balancing Rules - how to distribute traffic (5-tuple, 3-tuple, or 2-tuple)
NAT Rules - port forwarding to specific backend instances
Session Persistence - sticky sessions (None, Client IP, Client IP + Protocol)
For SQL Always On Availability Group with an Internal Load Balancer listener: use a TCP health probe on port 1433 (NOT HTTP). Also enable Floating IP - this is required for the listener to work properly.
| Component | Purpose |
|---|---|
| Frontend IP | Entry point - public, private, or both |
| Listener | Accepts requests on specific ports and protocols |
| Routing Rules | Defines how requests are routed (basic or path-based) |
| Backend Pool | Target servers receiving traffic |
| Health Probe | Validates availability of backend servers |
| WAF | Applies security filtering to incoming HTTP/S traffic |
| Method | Description |
|---|---|
| Basic routing | All traffic on a listener goes to one backend pool |
| Path-based routing | Routes based on URL path (e.g. /api → backend A, /web → backend B) |
| Multi-site routing | Routes based on hostname (e.g. site1.com vs site2.com on the same IP) |
If the question is 'route /loans to one backend and /cards to another using Application Gateway', the answer is PATH-BASED ROUTING. Multi-site is hostname-based. Round-robin is just even distribution and is not a separate routing method here.
Global Layer 7 load balancer with anycast IPs
Built-in CDN caching
Split-TCP - clients connect to the nearest point of presence
Backends can be in any region (or even on-premises with public connectivity)
WAF available on Standard and Premium tiers
Priority - failover order (active/passive)
Weighted - percentage-based distribution
Performance - route to closest endpoint by latency
Geographic - route based on user's geographic location
Multi-value - return multiple healthy endpoints
Subnet - route specific subnets to specific endpoints
| Service | Description | Speed | Use case |
|---|---|---|---|
| Site-to-Site VPN | Encrypted tunnel over the public internet | Up to 1.25 Gbps | Small offices, branch connectivity |
| Point-to-Site VPN | Individual computers to Azure VNet | Up to 1 Gbps | Remote workers, occasional access |
| ExpressRoute | Private dedicated connection - NOT over the internet | 50 Mbps to 100 Gbps | Enterprise, regulated industries, high security |
| ExpressRoute Global Reach | Connect on-prem sites via Microsoft backbone | Same as ExpressRoute | Use Microsoft backbone as a backup or primary inter-site path |
**When the question says **'avoid public internet for security reasons' The answer is ExpressRoute. Site-to-Site VPN goes OVER the internet (encrypted, but still on the public internet). ExpressRoute is private dedicated connectivity through a Microsoft Edge location. This is a high-frequency exam question.
| Type | Description |
|---|---|
| Policy-based (static) | Legacy. Single tunnel. Basic SKU only. Avoid unless required by old on-prem VPN device. |
| Route-based (dynamic) | Modern. Multiple tunnels. Supports Point-to-Site. Required for most scenarios including IKEv2. |
Route-based with IKEv2 is the default and correct answer for nearly all VPN scenarios on the exam. Policy-based only comes up in legacy/edge cases.
Point-to-Site uses self-signed certificates by default. If you need to add a second client computer to a Point-to-Site connection, you must EXPORT the client certificate from the working computer and INSTALL it on the new computer. Modifying Entra ID auth policies does not help.
If you add VNet peering or change the VPN gateway after Point-to-Site is configured, the existing VPN client package on user computers becomes INVALID. Users must download and reinstall the VPN client configuration package.
| Peering type | Used for |
|---|---|
| Private Peering | Connects your private IP space to your VNet (most common) |
| Microsoft Peering | Access to Microsoft 365, Dynamics 365, Azure PaaS services privately |
Managed networking service that simplifies hub-and-spoke at scale
Standard SKU supports Site-to-Site VPN, Point-to-Site, ExpressRoute, VNet-to-VNet
Basic SKU is Site-to-Site VPN only
Order to set up: Virtual WAN → Virtual Hub → VPN Sites → Connect to Hub
| Service | Purpose |
|---|---|
| Public DNS Zone | Host records accessible from the internet |
| Private DNS Zone | Internal name resolution within and across VNets |
| Azure Private DNS Resolver | Enables on-prem to query Azure private DNS zones (and vice versa) without deploying DNS forwarder VMs |
| Record | Purpose |
|---|---|
| A | Maps a name to an IPv4 address |
| AAAA | Maps a name to an IPv6 address |
| CNAME | Alias - maps a name to another name |
| MX | Mail exchange - mail server for the domain |
| TXT | Arbitrary text, often for domain verification |
| NS | Name server - delegates a subdomain to another DNS server |
| SRV | Service record - specifies host and port for services |
To add a custom domain to Entra ID, you must verify ownership. Create either a TXT record OR an MX record in the domain's DNS zone, then click verify in Azure.
Custom domains in Entra ID MUST be verified. The exam will trick you with 'you can add a custom domain but do not need to verify it' - this is False.
To delegate a subdomain (e.g. cicd.contoso.com) to a different DNS server, create an NS record in the parent zone (contoso.com) pointing to the new name servers.
Every Entra tenant comes with a default domain in the format <tenantname>.onmicrosoft.com. You cannot delete or change this. You can add custom domains and make them the primary.
Alias records point to an Azure resource directly (not a name). If the resource is deleted, the alias record becomes empty rather than dangling to an IP a bad actor could claim. Use for Public IPs, Traffic Manager profiles, App Gateways.
When you start a VM in Azure, a reverse DNS record in the form <vmname>.internal.cloudapp.net is automatically registered. So a reverse lookup of VM1's IP from within the same VNet returns VM1.internal.cloudapp.net.
| Feature | What it does | Cost |
|---|---|---|
| Service Endpoint | Restricts a PaaS service's public endpoint to specific subnets - still a public endpoint, just locked down | Free |
| Private Endpoint | Creates a PRIVATE IP in your VNet for the PaaS service - public endpoint can be disabled entirely | Paid (per hour + data) |
| Private Link Service | Lets you expose YOUR OWN service (behind a Standard LB) via Private Endpoints | Paid |
Service Endpoint vs Private Endpoint - the most-tested confusion Service Endpoint: subnet can use the PUBLIC endpoint, but the service knows about the subnet and can restrict access to that subnet only. Private Endpoint: gives the PaaS service a PRIVATE IP in your VNet. Reachable from peered VNets, on-prem (via VPN/ExpressRoute). Public endpoint can be turned off. If the question says 'must be accessible ONLY via private IP, no public exposure, even from peered VNets', the answer is Private Endpoint.
Ensures traffic never leaves the Microsoft backbone
Enables peered VNets and on-premises networks to access resources privately
Eliminates exposure to the public internet
Requires DNS configuration - private DNS zone for the service
Managed, cloud-native network firewall service - stateful, layer 4 and 7
Used for centralizing east-west and north-south traffic inspection
Has Basic, Standard, and Premium SKUs (Premium adds TLS inspection, IDPS, URL filtering)
Often deployed in a hub VNet, with spokes routing through it via UDRs