What is an Azure Virtual Network (VNet)?

An Azure VNet is a logically isolated network in Azure that enables resources like VMs, databases, and app services to communicate securely. VNets use private IP address spaces (like 10.0.0.0/16) and provide network segmentation, traffic filtering via NSGs, and connectivity to on-premises networks through VPN or ExpressRoute.

What is the difference between NSG and Azure Firewall?

Network Security Groups (NSGs) are basic Layer 3/4 packet filters applied to subnets or NICs, using allow/deny rules based on IP, port, and protocol. Azure Firewall is a managed Layer 7 firewall with FQDN filtering, threat intelligence, TLS inspection, and centralised logging. NSGs are free and sufficient for most scenarios; Azure Firewall adds enterprise features at cost.

How does VNet peering work in Azure?

VNet peering connects two VNets so resources can communicate using private IP addresses as if they were on the same network. Traffic stays on the Microsoft backbone (no public internet). Peering can be within the same region (VNet peering) or cross-region (global VNet peering). Peering is non-transitive, meaning if VNet A peers with B and B peers with C, A cannot reach C without a direct peering.

How many IP addresses does Azure reserve in each subnet?

Azure reserves 5 IP addresses in every subnet: the network address, default gateway, two DNS-mapped addresses, and the broadcast address. A /24 subnet (256 addresses) provides 251 usable IPs. Always account for these reserved addresses when planning subnet sizes.

What is a Network Security Group rule priority in Azure?

NSG rules are evaluated by priority number from lowest (highest priority) to highest (lowest priority), ranging from 100 to 4096. The first matching rule wins. Azure includes default rules at priority 65000-65500 that allow VNet-to-VNet traffic and deny all inbound by default. Place your custom rules between 100 and 4096.

Azure Virtual Networks: VNets, NSGs & Peering (AZ-104)

Networking in the cloud catches people off guard. You can’t just plug in a cable. Every VM needs a virtual network, every connection is software-defined, and if you don’t understand how Azure networking works, your resources will be isolated, exposed, or unreachable.

From the field: Virtual networking in Azure mirrors physical networking more closely than most people realise. The engineers I see struggling with Azure networking are usually the ones who skipped learning the fundamentals — subnetting, routing, firewall rules. If you understand those, Azure VNets make immediate sense.

This post covers Azure Virtual Networks – the foundation for everything else. VNets, subnets, IP addressing, peering, and connectivity options. This is 20-25% of the AZ-104 exam, and it’s knowledge you’ll use daily.

Career Impact

Why this matters: Cloud networking is one of the most in-demand skills. Companies struggle to find engineers who understand both traditional networking and cloud-native concepts.

Resume value: “Designed hub-spoke network topology for 50+ Azure VNets” or “Implemented NSG rules reducing attack surface by 80%”

Exam Coverage: Implement and Manage Virtual Networking (20-25%) – This includes virtual networks, subnets, IP addressing, NSGs, VNet peering, VPN Gateway, and DNS configuration.

What You’ll Learn

Virtual network architecture
IP addressing and subnets
Network Security Groups (NSGs)
VNet peering and connectivity
DNS and name resolution

Quick Reference

Concept	What It Is	Key Point
VNet	Virtual network	Isolated network in Azure
Subnet	Network segment	Divide VNet for organization/security
NSG	Network Security Group	Stateful firewall rules
ASG	Application Security Group	Group VMs for NSG rules
Peering	VNet-to-VNet connection	Non-transitive by default
VPN Gateway	On-prem connectivity	Site-to-site or point-to-site
Private Endpoint	Private access to PaaS	Keep traffic on Azure backbone

Virtual Network Basics

What is a VNet?

A VNet is your private network in Azure. It provides:

Isolation – Your resources, your network
Segmentation – Subnets for organization
Connectivity – To internet, on-prem, other VNets
Filtering – NSGs for traffic control
Routing – System routes and custom routes

VNet Properties

# Azure CLI - Create a VNet
az network vnet create \
  --name MyVNet \
  --resource-group az104-labs \
  --location uksouth \
  --address-prefixes 10.0.0.0/16

# Azure PowerShell - Create a VNet
New-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -AddressPrefix "10.0.0.0/16"

[SCREENSHOT: Azure Portal – Virtual Networks blade showing VNet creation form with address space configuration]

Key properties:

Address space – CIDR block(s) for the VNet (e.g., 10.0.0.0/16)
Region – VNets are regional (can’t span regions)
Subscription – VNets belong to one subscription
DNS servers – Custom or Azure-provided

Reserved Addresses

Azure reserves 5 IPs in every subnet:

Address	Purpose
x.x.x.0	Network address
x.x.x.1	Default gateway
x.x.x.2-3	Azure DNS
x.x.x.255	Broadcast

A /24 subnet has 256 addresses, but only 251 are usable.

Subnets

Subnet Design

Divide VNets into subnets for:

Security – Different NSG rules per subnet
Organization – Web tier, app tier, database tier
Service requirements – Some services need dedicated subnets

# Azure CLI - Add subnet to VNet
az network vnet subnet create \
  --name WebSubnet \
  --vnet-name MyVNet \
  --resource-group az104-labs \
  --address-prefixes 10.0.1.0/24

# Azure PowerShell - Add subnet to VNet
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
Add-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.1.0/24"
$VNet | Set-AzVirtualNetwork

Special Subnets

Some Azure services require dedicated subnets:

Service	Subnet Name	Notes
VPN Gateway	GatewaySubnet	Exactly this name, /27 minimum
Azure Firewall	AzureFirewallSubnet	/26 minimum
Azure Bastion	AzureBastionSubnet	/27 minimum
App Service VNet Integration	Delegated subnet	Service delegation

Subnet Delegation

Dedicate a subnet to a specific service:

# Azure CLI - Delegate subnet to App Service
az network vnet subnet update \
  --name AppServiceSubnet \
  --vnet-name MyVNet \
  --resource-group az104-labs \
  --delegations Microsoft.Web/serverFarms

# Azure PowerShell - Delegate subnet
$Delegation = New-AzDelegation -Name "appServiceDelegation" -ServiceName "Microsoft.Web/serverFarms"
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
Set-AzVirtualNetworkSubnetConfig -Name "AppServiceSubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.4.0/24" -Delegation $Delegation
$VNet | Set-AzVirtualNetwork

IP Addressing

Public IP Addresses

SKUs:

Basic – Dynamic or static, no availability zones
Standard – Static only, zone-redundant, required for Standard Load Balancer

# Azure CLI - Create public IP
az network public-ip create \
  --name MyPublicIP \
  --resource-group az104-labs \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

# Azure PowerShell - Create public IP
New-AzPublicIpAddress -Name "MyPublicIP" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -Sku "Standard" -AllocationMethod "Static" -Zone 1,2,3

Private IP Addresses

Assigned from subnet range:

Dynamic – Azure assigns, may change on restart
Static – You specify, doesn’t change

# Azure CLI - Create NIC with static private IP
az network nic create \
  --name MyNIC \
  --resource-group az104-labs \
  --vnet-name MyVNet \
  --subnet WebSubnet \
  --private-ip-address 10.0.1.10

# Azure PowerShell - Create NIC with static private IP
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -VirtualNetwork $VNet
New-AzNetworkInterface -Name "MyNIC" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -SubnetId $Subnet.Id -PrivateIpAddress "10.0.1.10"

IP Address Planning

Best practices:

Use RFC 1918 private ranges (10.x, 172.16-31.x, 192.168.x)
Don’t overlap with on-premises networks (if connecting later)
Plan for growth – easier to have large VNet than expand later
Document your IP allocation

Network Security Groups (NSGs)

What NSGs Do

NSGs are stateful firewalls. They filter traffic with rules based on:

Source/destination IP
Source/destination port
Protocol (TCP, UDP, Any)

NSG Rules

Each rule has:

Priority – 100-4096, lower = processed first
Source/Destination – IP, CIDR, service tag, ASG
Port – Single, range, or *
Protocol – TCP, UDP, ICMP, *
Action – Allow or Deny

Default Rules

Every NSG includes default rules you cannot delete:

Inbound:

Allow VNet to VNet (65000)
Allow Azure Load Balancer (65001)
Deny all inbound (65500)

Outbound:

Allow VNet to VNet (65000)
Allow to internet (65001)
Deny all outbound (65500)

[SCREENSHOT: Azure Portal – NSG rules blade showing default rules and custom rule configuration]

Creating NSG Rules

# Azure CLI - Create NSG
az network nsg create \
  --name WebNSG \
  --resource-group az104-labs

# Allow HTTP from anywhere
az network nsg rule create \
  --nsg-name WebNSG \
  --resource-group az104-labs \
  --name AllowHTTP \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes "*" \
  --destination-port-ranges 80

# Allow SSH from specific IP
az network nsg rule create \
  --nsg-name WebNSG \
  --resource-group az104-labs \
  --name AllowSSH \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes "203.0.113.50" \
  --destination-port-ranges 22

# Azure PowerShell - Create NSG
$NSG = New-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "az104-labs" -Location "uksouth"

# Allow HTTP from anywhere
$NSG | Add-AzNetworkSecurityRuleConfig -Name "AllowHTTP" -Priority 100 `
  -Direction Inbound -Access Allow -Protocol Tcp `
  -SourceAddressPrefix "*" -SourcePortRange "*" `
  -DestinationAddressPrefix "*" -DestinationPortRange 80
$NSG | Set-AzNetworkSecurityGroup

# Allow SSH from specific IP
$NSG | Add-AzNetworkSecurityRuleConfig -Name "AllowSSH" -Priority 110 `
  -Direction Inbound -Access Allow -Protocol Tcp `
  -SourceAddressPrefix "203.0.113.50" -SourcePortRange "*" `
  -DestinationAddressPrefix "*" -DestinationPortRange 22
$NSG | Set-AzNetworkSecurityGroup

NSG Association

NSGs can be associated with:

Subnets – All resources in subnet
Network interfaces – Specific VM

Both can apply – most restrictive wins.

# Azure CLI - Associate NSG with subnet
az network vnet subnet update \
  --name WebSubnet \
  --vnet-name MyVNet \
  --resource-group az104-labs \
  --network-security-group WebNSG

# Azure PowerShell - Associate NSG with subnet
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
$NSG = Get-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "az104-labs"
Set-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.1.0/24" -NetworkSecurityGroup $NSG
$VNet | Set-AzVirtualNetwork

Service Tags

Use service tags instead of IP addresses:

Tag	Includes
Internet	All public IPs
VirtualNetwork	VNet + peered + on-prem
AzureLoadBalancer	Azure infrastructure
AzureCloud	All Azure datacenter IPs
Storage	Azure Storage IPs
Sql	Azure SQL IPs

Application Security Groups (ASG)

Group VMs logically for NSG rules:

# Azure CLI - Create ASG
az network asg create --name WebServers --resource-group az104-labs

# Associate NIC with ASG
az network nic ip-config update \
  --name ipconfig1 \
  --nic-name MyNIC \
  --resource-group az104-labs \
  --application-security-groups WebServers

# Use ASG in NSG rule
az network nsg rule create \
  --nsg-name AppNSG \
  --resource-group az104-labs \
  --name AllowWebToApp \
  --priority 100 \
  --source-asgs WebServers \
  --destination-asgs AppServers \
  --destination-port-ranges 8080

# Azure PowerShell - Create ASG
$WebASG = New-AzApplicationSecurityGroup -Name "WebServers" -ResourceGroupName "az104-labs" -Location "uksouth"
$AppASG = New-AzApplicationSecurityGroup -Name "AppServers" -ResourceGroupName "az104-labs" -Location "uksouth"

# Use ASG in NSG rule
$NSG = Get-AzNetworkSecurityGroup -Name "AppNSG" -ResourceGroupName "az104-labs"
$NSG | Add-AzNetworkSecurityRuleConfig -Name "AllowWebToApp" -Priority 100 `
  -Direction Inbound -Access Allow -Protocol Tcp `
  -SourceApplicationSecurityGroup $WebASG `
  -DestinationApplicationSecurityGroup $AppASG `
  -SourcePortRange "*" -DestinationPortRange 8080
$NSG | Set-AzNetworkSecurityGroup

VNet Peering

What is Peering?

Connect VNets so resources can communicate using private IPs:

Low latency, high bandwidth
Traffic stays on Azure backbone
Works across regions (Global VNet Peering)
Works across subscriptions and tenants

Peering Characteristics

Non-transitive – VNet A peers with B, B peers with C. A cannot reach C through B.
Two-way – Must create peering from both VNets
No overlap – Address spaces cannot overlap

[DIAGRAM: VNet peering showing non-transitive nature – VNet A to B, B to C, but A cannot reach C directly]

# Azure CLI - VNet A to VNet B
az network vnet peering create \
  --name VNetA-to-VNetB \
  --resource-group az104-labs \
  --vnet-name VNetA \
  --remote-vnet VNetB \
  --allow-vnet-access

# Azure CLI - VNet B to VNet A
az network vnet peering create \
  --name VNetB-to-VNetA \
  --resource-group az104-labs \
  --vnet-name VNetB \
  --remote-vnet VNetA \
  --allow-vnet-access

# Azure PowerShell - VNet A to VNet B
$VNetA = Get-AzVirtualNetwork -Name "VNetA" -ResourceGroupName "az104-labs"
$VNetB = Get-AzVirtualNetwork -Name "VNetB" -ResourceGroupName "az104-labs"

Add-AzVirtualNetworkPeering -Name "VNetA-to-VNetB" -VirtualNetwork $VNetA `
  -RemoteVirtualNetworkId $VNetB.Id -AllowForwardedTraffic

# Azure PowerShell - VNet B to VNet A
Add-AzVirtualNetworkPeering -Name "VNetB-to-VNetA" -VirtualNetwork $VNetB `
  -RemoteVirtualNetworkId $VNetA.Id -AllowForwardedTraffic

Peering Options

Option	Purpose
Allow virtual network access	Basic connectivity
Allow forwarded traffic	Allow traffic from other networks
Allow gateway transit	Share VPN gateway
Use remote gateways	Use peer’s gateway

Hybrid Connectivity

VPN Gateway

Connect Azure to on-premises:

Types:

Site-to-Site (S2S) – Office to Azure, always-on
Point-to-Site (P2S) – Individual clients to Azure
VNet-to-VNet – Connect VNets through VPN (alternative to peering)

SKUs:

SKU	Tunnels	Throughput
VpnGw1	30	650 Mbps
VpnGw2	30	1 Gbps
VpnGw3	30	1.25 Gbps
VpnGw4	100	5 Gbps
VpnGw5	100	10 Gbps

# Azure CLI - Create gateway subnet
az network vnet subnet create \
  --name GatewaySubnet \
  --vnet-name MyVNet \
  --resource-group az104-labs \
  --address-prefixes 10.0.255.0/27

# Create public IP for gateway
az network public-ip create \
  --name VPNGatewayIP \
  --resource-group az104-labs \
  --allocation-method Static \
  --sku Standard

# Create VPN gateway (takes 30-45 minutes)
az network vnet-gateway create \
  --name MyVPNGateway \
  --resource-group az104-labs \
  --vnet MyVNet \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1 \
  --public-ip-address VPNGatewayIP

# Azure PowerShell - Create gateway subnet
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
Add-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.255.0/27"
$VNet | Set-AzVirtualNetwork

# Create public IP
$GatewayIP = New-AzPublicIpAddress -Name "VPNGatewayIP" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -AllocationMethod Static -Sku Standard

# Create VPN gateway (takes 30-45 minutes)
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $VNet
$IPConfig = New-AzVirtualNetworkGatewayIpConfig -Name "GatewayIPConfig" `
  -SubnetId $Subnet.Id -PublicIpAddressId $GatewayIP.Id
New-AzVirtualNetworkGateway -Name "MyVPNGateway" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -IpConfigurations $IPConfig -GatewayType Vpn `
  -VpnType RouteBased -GatewaySku VpnGw1

ExpressRoute

Private connection to Azure (not over internet):

Dedicated – Private circuit from your datacenter
High bandwidth – Up to 100 Gbps
Low latency – No internet hops
Expensive – Monthly circuit fee + data charges

Use for: Large data transfers, low-latency requirements, compliance requirements

DNS

Azure-Provided DNS

By default, VMs use Azure DNS (168.63.129.16):

Resolves Azure resource names
Resolves public DNS
No configuration needed

Custom DNS

# Azure CLI - Set custom DNS servers
az network vnet update \
  --name MyVNet \
  --resource-group az104-labs \
  --dns-servers 10.0.1.4 10.0.1.5

# Azure PowerShell - Set custom DNS servers
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
$VNet.DhcpOptions.DnsServers = @("10.0.1.4", "10.0.1.5")
$VNet | Set-AzVirtualNetwork

Azure DNS Zones

Host your domains in Azure:

Public zones – Internet-resolvable

# Azure CLI - Create public DNS zone
az network dns zone create \
  --name example.com \
  --resource-group az104-labs

# Add A record
az network dns record-set a add-record \
  --zone-name example.com \
  --resource-group az104-labs \
  --record-set-name www \
  --ipv4-address 203.0.113.10

# Azure PowerShell - Create public DNS zone
New-AzDnsZone -Name "example.com" -ResourceGroupName "az104-labs"

# Add A record
New-AzDnsRecordSet -Name "www" -RecordType A -ZoneName "example.com" `
  -ResourceGroupName "az104-labs" -Ttl 3600 `
  -DnsRecords (New-AzDnsRecordConfig -IPv4Address "203.0.113.10")

Private zones – VNet-only resolution

# Azure CLI - Create private DNS zone
az network private-dns zone create \
  --name private.example.com \
  --resource-group az104-labs

# Link to VNet
az network private-dns link vnet create \
  --name MyVNetLink \
  --zone-name private.example.com \
  --resource-group az104-labs \
  --virtual-network MyVNet \
  --registration-enabled true

# Azure PowerShell - Create private DNS zone
New-AzPrivateDnsZone -Name "private.example.com" -ResourceGroupName "az104-labs"

# Link to VNet
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
New-AzPrivateDnsVirtualNetworkLink -Name "MyVNetLink" -ResourceGroupName "az104-labs" `
  -ZoneName "private.example.com" -VirtualNetworkId $VNet.Id -EnableRegistration

Private Endpoints

The Problem

PaaS services (Storage, SQL, etc.) have public endpoints. Traffic goes over internet.

The Solution

Private Endpoints give PaaS services a private IP in your VNet:

# Azure CLI - Create private endpoint for storage
az network private-endpoint create \
  --name StoragePrivateEndpoint \
  --resource-group az104-labs \
  --vnet-name MyVNet \
  --subnet DataSubnet \
  --private-connection-resource-id /subscriptions/.../storageAccounts/mystorageaccount \
  --group-id blob \
  --connection-name StorageConnection

# Azure PowerShell - Create private endpoint for storage
$StorageAccount = Get-AzStorageAccount -ResourceGroupName "az104-labs" -Name "mystorageaccount"
$VNet = Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "az104-labs"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "DataSubnet" -VirtualNetwork $VNet

$PrivateLinkServiceConnection = New-AzPrivateLinkServiceConnection `
  -Name "StorageConnection" -PrivateLinkServiceId $StorageAccount.Id -GroupId "blob"

New-AzPrivateEndpoint -Name "StoragePrivateEndpoint" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -Subnet $Subnet -PrivateLinkServiceConnection $PrivateLinkServiceConnection

Traffic now stays on Azure backbone, using private IP.

Practice Lab: Complete VNet Setup

# Azure CLI - Complete VNet setup
# Create VNet with subnets
az network vnet create \
  --name LabVNet \
  --resource-group az104-labs \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name WebSubnet \
  --subnet-prefixes 10.0.1.0/24

az network vnet subnet create \
  --name AppSubnet \
  --vnet-name LabVNet \
  --resource-group az104-labs \
  --address-prefixes 10.0.2.0/24

az network vnet subnet create \
  --name DataSubnet \
  --vnet-name LabVNet \
  --resource-group az104-labs \
  --address-prefixes 10.0.3.0/24

# Create NSGs
az network nsg create --name WebNSG --resource-group az104-labs
az network nsg create --name AppNSG --resource-group az104-labs

# Web NSG rules
az network nsg rule create \
  --nsg-name WebNSG -g az104-labs \
  --name AllowHTTP --priority 100 \
  --direction Inbound --access Allow \
  --protocol Tcp --destination-port-ranges 80 443

# Associate NSGs
az network vnet subnet update \
  --name WebSubnet --vnet-name LabVNet \
  --resource-group az104-labs \
  --network-security-group WebNSG

az network vnet subnet update \
  --name AppSubnet --vnet-name LabVNet \
  --resource-group az104-labs \
  --network-security-group AppNSG

# Azure PowerShell - Complete VNet setup
# Create VNet
$VNet = New-AzVirtualNetwork -Name "LabVNet" -ResourceGroupName "az104-labs" `
  -Location "uksouth" -AddressPrefix "10.0.0.0/16"

# Add subnets
$VNet | Add-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -AddressPrefix "10.0.1.0/24"
$VNet | Add-AzVirtualNetworkSubnetConfig -Name "AppSubnet" -AddressPrefix "10.0.2.0/24"
$VNet | Add-AzVirtualNetworkSubnetConfig -Name "DataSubnet" -AddressPrefix "10.0.3.0/24"
$VNet | Set-AzVirtualNetwork

# Create NSGs
$WebNSG = New-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "az104-labs" -Location "uksouth"
$AppNSG = New-AzNetworkSecurityGroup -Name "AppNSG" -ResourceGroupName "az104-labs" -Location "uksouth"

# Add rules
$WebNSG | Add-AzNetworkSecurityRuleConfig -Name "AllowHTTP" -Priority 100 `
  -Direction Inbound -Access Allow -Protocol Tcp `
  -SourceAddressPrefix "*" -SourcePortRange "*" `
  -DestinationAddressPrefix "*" -DestinationPortRange 80,443
$WebNSG | Set-AzNetworkSecurityGroup

# Associate NSGs
$VNet = Get-AzVirtualNetwork -Name "LabVNet" -ResourceGroupName "az104-labs"
Set-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.1.0/24" -NetworkSecurityGroup $WebNSG
Set-AzVirtualNetworkSubnetConfig -Name "AppSubnet" -VirtualNetwork $VNet `
  -AddressPrefix "10.0.2.0/24" -NetworkSecurityGroup $AppNSG
$VNet | Set-AzVirtualNetwork

Interview Questions

Q1: “Explain NSG rule processing order.”

Good Answer: “NSGs process rules by priority number, lowest first. A priority 100 rule is evaluated before priority 200. Processing stops at the first match – if traffic matches an allow rule at 100, it’s allowed even if there’s a deny at 200. The default rules at 65000+ can’t be deleted but can be overridden with lower priority rules. Both subnet and NIC NSGs apply if both exist – traffic must be allowed by both.”

Q2: “When would you use VNet peering vs VPN Gateway?”

Good Answer: “VNet peering for Azure-to-Azure connectivity – it’s simpler, lower latency, higher throughput, and cheaper. VPN Gateway for connecting to on-premises or when you need encryption in transit. You can also use gateway transit with peering – peer VNets to a hub that has the VPN gateway, so spokes can reach on-premises through the hub. For most Azure-only scenarios, peering is the right choice.”

Q3: “How do private endpoints improve security?”

Good Answer: “By default, PaaS services like Storage and SQL have public endpoints – traffic goes over the internet. Private endpoints give these services a private IP address in your VNet. Traffic stays on Azure’s backbone network, never touching the public internet. You can then disable public access entirely. This reduces attack surface, satisfies compliance requirements, and keeps data off the public internet. Combined with private DNS zones, resources resolve to private IPs automatically.”

Key Exam Points

VNets are regional – Can’t span regions without peering
5 IPs reserved per subnet – Plan accordingly
NSG priority – Lower number = higher priority
Peering is non-transitive – A→B, B→C doesn’t mean A→C
GatewaySubnet – Exact name required for VPN/ExpressRoute
Service tags – Use instead of hardcoding IPs

Career Application

On your resume:

“Designed hub-spoke network topology for 50+ Azure VNets”
“Implemented NSG rules reducing attack surface by 80%”
“Configured hybrid connectivity with ExpressRoute for enterprise workloads”

Demonstrate:

Understanding of OSI model concepts
Security-first thinking
Hybrid networking experience
Cost awareness (peering vs gateway)

Next Steps

Next in series: Azure Storage – Storage accounts and services

Related: Windows Networking – On-prem networking

Lab: Build a three-tier network with proper NSG rules

Networking is the plumbing of the cloud. Get it right and everything flows. Get it wrong and nothing works. There’s no in-between.

This guide is part of the Azure AZ-104 Study Series. See the full series for more guides like this.

Related Guides

If you found this useful, these guides continue the journey:

Azure Identity and Governance — identity is the new perimeter
Azure Storage — the next module in the series
Azure AZ-104 Series — the full study path
IP Addressing Fundamentals — the networking basics that underpin everything in Azure

The RTM Essential Stack - Gear I Actually Use

ReadTheManualTech

ReadTheManual is run, written and curated by Eric Lonsdale.

Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.

He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.

From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.

ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.

Enjoyed this guide?

New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.