Microsoft AZ-104: Azure Virtual Networking — Study Guide

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Part of the Microsoft Azure Administrator Associate AZ-104 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Virtual Networking establishes the software-defined data center fabric for IaaS and PaaS workloads. You design an address plan with CIDR, carve subnets aligned to trust boundaries, secure east-west and north-south flows with Network Security Groups (NSGs) and Azure Firewall, connect environments using VNet peering, VPN Gateway, or ExpressRoute, shape traffic with user-defined routes, and provide reliable name resolution with Azure DNS. Getting these constructs right enables scalable hub-and-spoke designs, secure PaaS access via Private Endpoints, and predictable routing that satisfies compliance and performance requirements.

Addressing, Segmentation, and Policy (VNets, Subnets, NSGs, ASGs, UDR)

A virtual network defines one or more non-overlapping RFC1918 address spaces using CIDR notation (for example, 10.0.0.0/16). You can add additional address prefixes later if no conflicts exist with peers. Subnets segment the VNet into routable blocks (for example, 10.0.1.0/24 for web, 10.0.2.0/24 for app). Reserve a dedicated GatewaySubnet for VPN/ExpressRoute gateways; allocate generously (at least /27) to avoid future scaling limits. IP allocation is dynamic by default; you can set static private IPs on NICs when needed.

Default system routes allow intra-VNet traffic and send 0.0.0.0/0 to the internet (subject to public IP presence). User-defined routes (UDR) override these defaults at the subnet level. Create a route table and associate it with a subnet; entries include:

Next hop: Virtual appliance (an NVA’s IP on the same VNet), Virtual network gateway (to steer to on-prem via VPN/ExpressRoute), Internet (force internet egress), or None (blackhole).
Forced tunneling: Send 0.0.0.0/0 to a virtual network gateway to force all outbound traffic on-prem, or to an NVA/Azure Firewall for centralized egress control. If using BGP with a gateway that advertises a default route, consider disabling gateway route propagation on specific subnets to prevent unintended path selection.

NSGs enforce stateful L3–L4 policy on NICs or subnets; both scopes can be used simultaneously and traffic must be allowed by all applicable NSGs. Rules evaluate by priority (100–4096; lower numbers first) and direction (inbound/outbound). Default rules include:

Inbound: AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Outbound: AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Override defaults with custom rules of higher precedence. Use service tags (for example, Internet, AzureLoadBalancer, Storage) to simplify maintenance, and IP Groups for reusable address lists.

Application Security Groups (ASGs) decouple IP addressing from policy. Assign NICs to ASGs that represent roles (for example, Web, App, DB) and reference those ASGs in NSG rules. This allows policy changes without touching IPs or subnets and aids consistent role-based segmentation within a VNet.

Connectivity Options: Peering, VPN Gateway, and ExpressRoute

VNet peering connects VNets over the Microsoft backbone with low latency and high bandwidth. Local peering is within a region; global peering spans regions. Peering is non-transitive and requires non-overlapping address spaces. Key flags:

Allow virtual network access enables routed connectivity between peers.
Allow forwarded traffic permits traffic forwarded by NVAs to traverse the peering.
Use remote gateways lets a VNet use a VPN/ER gateway in a peered “hub.” The hub must Allow gateway transit. A VNet can use remote gateways from only one peer. Peered VNets do not automatically receive P2S client routes; end users must install updated VPN client configurations that include routes to new spokes.

Azure VPN Gateway provides IPSec/IKE tunnels:

Site-to-site (S2S) connects on-premises VPN devices to Azure; use route-based VPN (IKEv2) for most scenarios, especially with BGP and multiple tunnels.
Point-to-site (P2S) enables individual clients (Windows, macOS, Linux) to connect using OpenVPN, IKEv2, or SSTP. Client configuration contains static routes to Azure prefixes; re-download when address spaces change or you add reachable spokes behind a hub.
VNet-to-VNet uses S2S within Azure regions/tenants, requiring non-overlapping addresses. Useful when peering isn’t possible (for example, cross-tenant with administrative boundaries).
SKUs: Prefer VpnGw1–VpnGw5 (and AZ variants for zone redundancy). Basic is legacy and lacks features (no IKEv2/BGP). Route-based supports P2S, BGP, and active-active. Policy-based is limited (S2S only, no BGP).
BGP advertises prefixes dynamically, supports transit across multiple tunnels, and simplifies route failover. VPN NAT rules can translate overlapping on-prem/Azure prefixes when unavoidable.

ExpressRoute delivers private, SLA-backed connectivity over a partner’s circuit into Microsoft’s edge:

A circuit is provisioned by the provider (bandwidth, metering, SKU) and linked to your subscription via a service key. Redundancy is built in: each circuit exposes dual primary/secondary connections; your router should establish dual BGP sessions for HA.
Peering types:
- Private peering carries private RFC1918 traffic to VNets via an ExpressRoute virtual network gateway (ErGw1AZ–ErGw3AZ). Supports BGP, fast failover, and optional FastPath for data-plane acceleration.
- Microsoft peering exposes public Microsoft services (for example, Storage, SQL, Microsoft 365) via public IPs with route filters. Use for internet-facing endpoints while staying off the public internet. Microsoft 365 requires additional review.
Use ExpressRoute Global Reach to interconnect on-prem sites via Microsoft’s backbone. For forced tunneling, advertise a default route over private peering, or pair with UDRs/Azure Firewall for selective egress.

Coexistence: A VNet can have both VPN and ExpressRoute gateways using the same GatewaySubnet; use gateway transit and UDRs to control flows. ExpressRoute is preferred for steady-state enterprise traffic; VPN serves as backup or for branch/small-office reach.

Name Resolution and Secure Access to PaaS (Azure DNS, Endpoints)

Azure DNS hosts public zones so your internet-facing records reside on Azure’s global DNS platform with high availability. For intra-VNet resolution, Azure DNS Private Zones provide split-horizon name service. Link VNets to a private zone to enable resolution; optionally enable auto-registration so VM A records register and update automatically upon NIC IP changes. For hybrid name resolution and conditional forwarding between Azure and on-premises, deploy Azure DNS Private Resolver with inbound/outbound endpoints and rule sets that forward selected domains (for example, corp.contoso.com to on-prem DNS, or privatelink.* back into Azure).

Service Endpoints extend your VNet’s identity to selected Azure services (for example, Storage, SQL) over the Microsoft backbone, retaining the service’s public IP. On the PaaS firewall, restrict access to specific VNet/subnet. They are easy to enable per subnet and per service, require no DNS changes, and work well for simple, Azure-only scenarios. However, the resource still has a public IP and is not addressable privately from on-prem without going through the public endpoint.

Private Endpoints place a NIC with a private IP from your subnet on the PaaS resource via Private Link. Traffic stays on the private network, enabling fine-grained data exfiltration control and access from on-prem over VPN/ExpressRoute. Proper DNS is essential: override the resource’s public FQDN to resolve to its privatelink FQDN, which points at your private IP. Use Azure Private DNS zones (for example, privatelink.blob.core.windows.net) linked to VNets. Choose Private Endpoints when you need true private addressing, cross-premises access, and strict egress controls.

Azure Firewall and Centralized Egress/Ingress Governance

Azure Firewall is a stateful, cloud-native firewall that scales elastically and provides central policy for hub-and-spoke designs. Deploy it into a dedicated AzureFirewallSubnet. For forced tunneling scenarios, add AzureFirewallManagementSubnet so management traffic uses the internet while data traffic follows your default route.

Rule collection types apply in this order and by rule collection priority:

DNAT rules translate inbound public IPs/ports on the firewall to private addresses (for example, map firewall public IP:443 to a web VM). Pair with NSGs on the destination subnet to enforce least privilege.
Network rules filter L3–L4 traffic (source/destination IPs, protocols, ports). Use for non-HTTP(S) protocols and to control outbound/intra-spoke flows.
Application rules control outbound HTTP/S by FQDN or FQDN tags (for example, WindowsUpdate). Premium SKU adds TLS inspection and IDPS for deep HTTP(S) filtering. Threat intelligence can be set to Alert or Deny to act on known malicious IPs/domains. Combine Azure Firewall with UDRs (0.0.0.0/0 to the firewall as virtual appliance) to centralize egress; allow forwarded traffic on peering for spokes. Log to Log Analytics for auditing and analytics, and use policy hierarchies/Azure Firewall Manager to standardize at scale.

Practical Problem Scenario

Adobe must modernize a hybrid network: a secure hub in Azure must provide centralized internet egress, on-prem connectivity with high availability, private access to Storage and SQL, and predictable name resolution across Azure and data centers. Remote developers also need P2S access to all spokes.

Design address space and segmentation

Create Hub VNet 10.0.0.0/16 with subnets: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Create Spoke VNets for Apps 10.1.0.0/16 and Data 10.2.0.0/16.
Rationale: Non-overlapping CIDR enables peering and future growth; dedicated subnets meet platform requirements and simplify UDR/NSG scoping.

Establish hub-and-spoke connectivity

Peer Hub↔Apps and Hub↔Data with Allow virtual network access and Allow forwarded traffic. On the hub, set Allow gateway transit; on spokes, set Use remote gateways.
Rationale: Centralizes north-south flows via the hub gateway/firewall while permitting east-west via the hub, avoiding mesh complexity.

Provide private, redundant on-prem connectivity

Order an ExpressRoute circuit (Private Peering) through a provider; configure dual BGP sessions. Deploy an ExpressRoute virtual network gateway (ErGw2AZ) in the hub’s GatewaySubnet and link the circuit.
Rationale: Private, SLA-backed connectivity with built-in redundancy and zone-redundant gateway meets enterprise HA and performance needs.

Centralize egress and protect workloads

Deploy Azure Firewall Standard in AzureFirewallSubnet. Create UDR on each spoke subnet: 0.0.0.0/0 next hop Virtual appliance → firewall private IP. Add NSGs to spokes allowing only required ports to the firewall and intra-VNet.
Rationale: Azure Firewall + UDRs enforce consistent egress policy, logging, and threat intelligence; NSGs provide micro-segmentation at the subnet/NIC level.

Secure PaaS with true private access

Create Private Endpoints for Storage and SQL in the Data spoke. Link Azure Private DNS zones (privatelink.blob.core.windows.net, privatelink.database.windows.net) to Hub and Spokes. Disable public network access on the PaaS resources.
Rationale: Private Endpoints eliminate public exposure and allow access from on-prem via ExpressRoute; Azure Private DNS ensures correct name resolution.

Implement hybrid name resolution and conditional forwarding

Deploy Azure DNS Private Resolver in the hub with inbound/outbound endpoints. Create rules to forward corp.adobe.com queries to on-prem DNS and resolve privatelink zones within Azure.
Rationale: Provides deterministic, split-horizon DNS across Azure and on-prem without custom DNS VMs.

Enable remote developer access to all spokes

Configure a P2S VPN on the hub VPN Gateway alongside ExpressRoute (coexistence). Distribute the VPN client profile. After adding spokes, re-download the client package so routes to 10.1.0.0/16 and 10.2.0.0/16 are included.
Rationale: Hub-based P2S simplifies operations and, with updated client routes and peering gateway transit, gives users reachability to all spokes.

Harden with ASGs and NSGs

Assign NICs to ASGs (Web, App, DB) and implement NSG rules allowing Web→App (TCP 443), App→DB (TCP 1433) by ASG, denying all else. Retain default rules where appropriate.
Rationale: Role-based policy scales without IP management and enforces least privilege.

This architecture meets Adobe’s requirements with ExpressRoute redundancy, centralized Azure Firewall governance, private PaaS access, and coherent DNS, while ensuring remote users and on-prem systems can securely reach every workload through the hub.

← Azure Virtual Machines and Compute · All domains · Azure Load Balancing and Traffic Management →

Practice these questions → · Timed practice on ExamRoll.io →