Microsoft AZ-900: Networking — Study Guide

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Azure networking provides the foundation for securely connecting workloads, users, and services across regions and between on-premises and cloud environments. It spans private software-defined networks, hybrid connectivity, global traffic distribution, and layered defenses against threats. Sound designs start with clear address planning, isolation boundaries, and name resolution, then add the right mix of connectivity and protection to meet performance and compliance goals.

Core virtual networking: VNets, subnets, IP addressing, and DNS

A virtual network (VNet) is the isolation boundary for private networking in Azure. VNets span a single region, are scoped to a subscription, and use RFC1918 address spaces that you define. Within a VNet, subnets segment address space into logical tiers (for example, web, app, and data). Subnets support network policies such as network security groups (NSGs), route tables, service endpoints, and delegation to specific PaaS services. Thoughtful CIDR planning avoids overlaps with on-premises networks and other VNets you may peer in the future. IP addressing in Azure includes private and public addresses. Private IPs attach to NICs on virtual machines and other resources for east-west traffic inside a VNet or across peering and VPN/ExpressRoute. Private IPs can be dynamic or static within a subnet. Public IPs expose resources to the internet or provide outbound connectivity using NAT. Standard public IPs are zone-redundant where available, are closed to inbound by default, and should be combined with load balancers, Application Gateways, or Azure Firewall rather than assigned directly to VMs unless there is a strong justification. Name resolution is handled by the Azure-provided DNS resolver (168.63.129.16) by default, which resolves hostnames within a VNet. For private endpoints and hybrid name resolution, Azure Private DNS zones map private FQDNs (for example, privatelink.database.windows.net) to private IP addresses. You can link private DNS zones to multiple VNets. If you use custom DNS servers, ensure conditional forwarding covers Azure Private DNS zones so resources resolve private endpoints instead of public service endpoints.

• Scope
  • Private IP: Within VNet/peered/hybrid networks
  • Public IP: Internet-facing
• Assignment
  • Private IP: Dynamic or static per NIC/subnet
  • Public IP: Dynamic or static; Standard SKU recommended
• Common uses
  • Private IP: VM-to-VM, Private Link, internal load balancing
  • Public IP: Inbound via LB/App Gateway; outbound SNAT/NAT Gateway
• Security posture
  • Private IP: Controlled by NSGs, UDRs
  • Public IP: Closed by default (Standard); restrict with NSGs/Firewall

Hybrid and private connectivity: VPN Gateway, ExpressRoute, VNet peering, and Private Link

Azure VPN Gateway establishes encrypted tunnels using IPsec/IKE for site-to-site (S2S), point-to-site (P2S), and VNet-to-VNet connections. It is a cost-effective way to extend your on-premises network into Azure over the public internet while keeping data encrypted in transit. Throughput and tunnel counts scale with the VpnGw SKU, and high availability is achieved by default with active/standby instances. Active-active and BGP support enable dynamic routing and higher aggregate throughput. ExpressRoute provides private, SLA-backed Layer 3 connectivity to Microsoft over a partner’s edge or direct peering. Traffic stays off the public internet, offering predictable latency and higher bandwidth options. ExpressRoute circuits support multiple peerings (Azure private, Microsoft, and Microsoft 365 where applicable) and use dual redundant connections. It is the preferred option for mission-critical and high-throughput scenarios, often combined with a hub-and-spoke topology where the hub VNet hosts the ExpressRoute or VPN Gateway. VNet peering links VNets over Microsoft’s backbone with low latency and high bandwidth, allowing resources to communicate using private IPs as if on the same network. Peering is non-transitive: traffic does not automatically route through a peered VNet to a third VNet. Gateway transit can be enabled so spoke VNets use the hub’s VPN or ExpressRoute gateway. For accessing PaaS over private IP, Private Link creates a private endpoint (a NIC in your subnet) that maps to a specific service instance such as Azure Storage, SQL Database, or a private service you publish. Traffic flows entirely on the Azure backbone, and DNS is pivotal to ensure clients resolve to the private endpoint. Choosing among these options depends on requirements: VPN Gateway for encrypted connectivity over the internet, ExpressRoute for private high-performance circuits, VNet peering for intra-Azure private connectivity, and Private Link for private access to PaaS or partner services without exposing public endpoints.

• VPN Gateway
  • Connectivity layer: L3 (IPsec/IKE)
  • Scope: On-prem <-> Azure; VNet <-> VNet
  • Typical bandwidth: Hundreds of Mbps to multi-Gbps (per SKU)
  • Encryption: Yes (IPsec)
  • Key strengths: Cost-effective, flexible, P2S/S2S
  • Primary use cases: Hybrid extension, dev/test, quick enablement
• ExpressRoute
  • Connectivity layer: L3 private circuit
  • Scope: On-prem <-> Azure (via partner)
  • Typical bandwidth: 50 Mbps–100 Gbps (by circuit)
  • Encryption: Private circuit (no IPsec required)
  • Key strengths: Predictable latency, high throughput, SLA
  • Primary use cases: Mission-critical hybrid, data replication, compliance
• VNet Peering
  • Connectivity layer: Azure backbone
  • Scope: VNet <-> VNet (same or global)
  • Typical bandwidth: VM NIC/host limited; low latency
  • Encryption: No (private backbone)
  • Key strengths: Simple, fast, trans-tenant support
  • Primary use cases: Hub-spoke, regional/global VNet mesh
• Private Link
  • Connectivity layer: L7 endpoint via private NIC
  • Scope: Client VNet <-> PaaS/Private service
  • Typical bandwidth: App-dependent; NIC-limited
  • Encryption: Backbone isolation
  • Key strengths: Eliminates public exposure, granular
  • Primary use cases: Private access to Storage, SQL, Key Vault, partner apps

Traffic distribution and acceleration: Load Balancer, Application Gateway, Front Door, Traffic Manager, and CDN

Azure Load Balancer operates at Layer 4 for TCP/UDP and provides high-performance, low-latency load balancing within a region. It supports inbound and outbound scenarios, inbound NAT rules, and health probes. Standard Load Balancer is zone-aware and can span zones in a region for resilience. It is the right choice for non-HTTP protocols, gaming backends, and scenarios requiring HA ports or SNAT for outbound connectivity at scale via outbound rules or NAT Gateway. Application Gateway provides Layer 7 HTTP/HTTPS routing with features such as URL path- and host-based routing, cookie affinity, and SSL offload. When enabled with the Web Application Firewall (WAF) SKU, it offers managed OWASP rule sets to help protect against common exploits and bots. Application Gateway is regional and often used in front of VM Scale Sets, Containers, or App Services in private network configurations, especially where rich HTTP routing and WAF inspection are required. Azure Front Door is a global, anycast, Layer 7 entry point that accelerates and protects internet-facing web applications. It provides global load balancing with instant failover, smart pathing, and built-in WAF. Front Door Standard/Premium integrates CDN capabilities for static and dynamic content acceleration at the edge, and can origin to Application Gateways, App Services, or Storage. Traffic Manager complements these services by performing DNS-based global distribution across any endpoints (HTTP or non-HTTP), using methods such as priority, performance, weighted, geographic, subnet, and multi-value routing. For static content offload, Azure CDN (including Front Door Standard/Premium or Azure CDN from Microsoft/Verizon/Akamai) caches content closer to users, reduces origin load, and improves performance. Combining services is common. A typical internet-facing design uses Azure Front Door with WAF for global ingress, origining to regional Application Gateways (with or without WAF) that route to internal workloads. For protocols other than HTTP/HTTPS, pair Traffic Manager for DNS failover with regional Load Balancers. Place public IPs only on these managed edges, keeping application VMs private.

• Azure Load Balancer
  • Layer: L4
  • Scope: Regional
  • Protocols: TCP/UDP
  • WAF support: No
  • Session affinity: No (at L7)
  • Common use cases: Non-HTTP workloads, internal load balancing, outbound SNAT
• Application Gateway
  • Layer: L7
  • Scope: Regional
  • Protocols: HTTP/HTTPS
  • WAF support: Yes (WAF v2)
  • Session affinity: Yes (cookie-based)
  • Common use cases: Web apps in VNets, SSL offload, path/host routing
• Azure Front Door
  • Layer: L7
  • Scope: Global
  • Protocols: HTTP/HTTPS
  • WAF support: Yes (WAF)
  • Session affinity: Yes (affinity cookie)
  • Common use cases: Global entry, edge acceleration, instant failover
• Traffic Manager
  • Layer: DNS
  • Scope: Global
  • Protocols: Any (DNS-based)
  • WAF support: No
  • Session affinity: No
  • Common use cases: Cross-region failover/load distribution for any endpoint
• Azure CDN
  • Layer: L7 cache
  • Scope: Global
  • Protocols: HTTP/HTTPS
  • WAF support: No (use Front Door WAF)
  • Session affinity: N/A
  • Common use cases: Static content caching, origin offload, performance

Network security and secure access: NSGs, Azure Firewall, DDoS Protection, Bastion, and Just-in-Time

Network Security Groups (NSGs) apply stateful Layer 3/4 filtering to subnets and NICs. Rules allow or deny traffic based on 5-tuple parameters, with support for service tags and application security groups to simplify management. NSGs are ideal for segmenting tiers, restricting management ports, and enforcing least privilege between subnets. They are fast and distributed, but they do not provide application-layer filtering, intrusion prevention, or centralized DNAT/SNAT. Azure Firewall is a managed, stateful firewall and network security service that provides both network rules and application rules (FQDN filtering). The Premium SKU adds TLS inspection, IDPS, and URL filtering. It supports DNAT/SNAT, threat intelligence–based filtering, and integrates with route tables for a central egress control point in hub-and-spoke topologies. Azure Firewall complements NSGs: NSGs enforce local east-west micro-segmentation, while the firewall enforces centralized north-south and internet egress policies. Azure DDoS Protection comes in Basic and Standard offerings. Basic is platform-level protection applied automatically to Azure services with no customer configuration. Standard adds adaptive tuning, telemetry, alerting, and rapid mitigation for resources with public IPs within a protected VNet, plus cost-protection credits during documented attacks. For administrative access without public IPs, Azure Bastion provides RDP/SSH over TLS directly from the Azure portal (and supported native clients in Bastion Standard), eliminating inbound exposure. Just-in-Time (JIT) VM access, enabled through Microsoft Defender for Cloud, keeps management ports closed in NSGs and opens time-bound access only to approved users and source IPs, minimizing the attack surface while preserving operational access.

• OSI focus
  • NSG: L3/L4 (stateful)
  • Azure Firewall: L3–L7 (stateful)
  • DDoS Protection Standard: Volumetric/L3/L4 defense
  • Azure Bastion: Secure RDP/SSH access
  • JIT VM Access: Access time control
• Central policy mgmt
  • NSG: Limited (per subnet/NIC)
  • Azure Firewall: Yes (policy, rules, IDPS)
  • DDoS Protection Standard: Yes (per protected VNet)
  • Azure Bastion: Not applicable
  • JIT VM Access: Policy via Defender for Cloud
• DNAT/SNAT
  • NSG: No
  • Azure Firewall: Yes
  • DDoS Protection Standard: No
  • Azure Bastion: No
  • JIT VM Access: No
• WAF/IDPS
  • NSG: No
  • Azure Firewall: Premium: IDPS
  • DDoS Protection Standard: N/A
  • Azure Bastion: No
  • JIT VM Access: No
• Primary value
  • NSG: Micro-segmentation
  • Azure Firewall: Centralized control and inspection
  • DDoS Protection Standard: Attack mitigation for public IPs
  • Azure Bastion: No public IPs for admin
  • JIT VM Access: Closes mgmt ports except when needed

Practical Problem: Global retail rollout for Contoso Outdoors: secure, private, and highly available network

Scenario: Contoso Outdoors is launching a new e-commerce platform backed by microservices running on Azure across East US and West Europe. The company must keep all application VMs private, provide secure administrative access, and enable partners to upload inventory files to Azure Storage without traversing the public internet. The on-premises ERP in Chicago needs low-latency, private connectivity to services in East US. The web front end must be resilient to a single regional failure and protect against common web exploits and volumetric attacks.

Challenge: Design a network that combines private address spaces, hybrid connectivity, global HTTP distribution, private access to PaaS, and layered security without exposing VM public IPs.

Recommended Approach:

1. Create a hub-and-spoke architecture in each region. Deploy a hub VNet with address space 10.0.0.0/16 and spokes for web, app, and data tiers using non-overlapping /24 subnets. Associate NSGs to each subnet to enforce tier-to-tier least privilege.
2. Deploy Azure Firewall Premium in each hub. Configure UDRs in the spokes to route all internet-bound traffic to the firewall for egress control, TLS inspection, and threat intelligence filtering.
3. Establish hybrid connectivity from the Chicago datacenter to the East US hub with ExpressRoute (private peering). Enable dual connections for redundancy and BGP for dynamic routing. Temporarily use a site-to-site VPN as failover if required.
4. Peer regional spokes to their local hub VNets using VNet peering. Enable gateway transit so spokes consume the hub’s ExpressRoute/VPN gateway. Use global VNet peering to connect the East US and West Europe hubs for control-plane and replication traffic.
5. Publish the e-commerce site with Azure Front Door Premium and WAF. Configure two origins: East US and West Europe Application Gateways. Enable Front Door managed WAF policies and bot protection. Turn on Front Door caching for static assets.
6. In each region, deploy Application Gateway WAF v2 in the web spoke, terminating TLS and performing path- and host-based routing to backend pools (VM Scale Sets or App Services) in private subnets. Use Standard Load Balancers internally for non-HTTP microservices.
7. For partner and service-to-service private access, create Private Endpoints to Azure Storage and Azure SQL Database in the data spokes. Link appropriate Azure Private DNS zones to all spokes and hubs, and configure on-premises DNS to forward privatelink zones to Azure for consistent name resolution.
8. Protect public-facing surfaces with Azure DDoS Protection Standard by enabling it on the hub VNets that contain public IP resources for Application Gateway and Front Door origins. Monitor attack metrics and configure alerts.
9. Provide secure administration by deploying Azure Bastion Standard in each hub VNet. Remove all public IPs from VMs. Enable Just-in-Time VM access in Defender for Cloud so RDP/SSH is time-bound and source-restricted when tunneled through Bastion.
10. Instrument the network with NSG flow logs, Azure Firewall logs, and Front Door/Application Gateway access logs to Log Analytics. Configure health probes and synthetic tests to validate end-to-end availability and failover behavior.

Azure Rationale: This design keeps application planes private and controlled while presenting a hardened global edge. ExpressRoute delivers private, predictable connectivity for the ERP system, with VNet peering and gateway transit extending access to all spokes. Azure Front Door with WAF provides global HTTP distribution, instant failover, and edge security, while regional Application Gateways handle L7 routing and WAF close to the workloads. Private Link eliminates public exposure for Storage and SQL, backed by private DNS for seamless resolution from Azure and on-premises. NSGs enforce micro-segmentation; Azure Firewall centralizes egress, DNAT/SNAT, and advanced inspection; DDoS Protection Standard mitigates volumetric attacks against public endpoints. Azure Bastion and JIT deliver secure, auditable administrative access without opening management ports or assigning VM public IPs, meeting security and compliance objectives without sacrificing operability.

← Compute · All domains · Storage →

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

Browse Microsoft →