Azure Fundamentals – Networking

Module 1 – Azure Virtual Network (VNet)

Characteristics

• Scope: scoped to a single Azure region.
• Address space: defined in CIDR notation (e.g.: 10.1.0.0/16 = 65,536 IP addresses).
• Isolation: each VNet is isolated by default from other VNets and from the Internet.
• DNS: integrated Azure DNS or custom DNS.

Subnets

VNet: 10.1.0.0/16
  ├── Subnet Frontend: 10.1.1.0/24 (254 hosts)
  ├── Subnet Backend: 10.1.2.0/24
  └── Subnet Data: 10.1.3.0/24

Azure reserves 5 addresses per subnet (network, gateway, DNS x2, broadcast).

VNet Peering

VNet1 (10.1.0.0/16) ←→ VNet2 (10.2.0.0/16)

• Direct communication between VNets (same region or cross-region).
• Traffic routes via the Microsoft backbone (not Internet).
• No gateway required.
• Non-transitive: if VNet1-VNet2 are peered and VNet2-VNet3 are peered, VNet1 cannot talk to VNet3.

Module 2 – Network Security Groups (NSG)

Concept

• Firewall rules for subnets or network interfaces (NIC).
• Inbound and Outbound.
• Priority: 100 to 4096 (smaller = higher priority).
• Processed from smallest to largest priority number.

Default Rules (non-deletable)

NSG Rule Example

{
  "name": "Allow-HTTP",
  "priority": 100,
  "direction": "Inbound",
  "access": "Allow",
  "protocol": "Tcp",
  "sourcePortRange": "*",
  "destinationPortRange": "80",
  "sourceAddressPrefix": "*",
  "destinationAddressPrefix": "*"
}

Application Flow Tags

• Internet: all public Internet IPs.
• VirtualNetwork: VNet address space + all peered VNets.
• AzureLoadBalancer: Azure Load Balancer health probes.

Module 3 – Azure VPN Gateway

Use Cases

Connect on-premises networks (office, datacenter) to an Azure VNet securely.

Types

Site-to-Site Architecture

On-Premises Network (192.168.0.0/16)
  ↕ IPSec Tunnel (encrypted)
Azure VPN Gateway (10.0.0.254)
  ↕
Azure VNet (10.0.0.0/16)

BGP support: dynamic routing for complex multi-site topologies.

VPN Gateway SKUs

Module 4 – Azure ExpressRoute

Differences vs VPN

ExpressRoute Use Cases

• Financial organizations with strict latency requirements.
• Massive data migrations.
• Regulatory compliance (sensitive data, HIPAA, etc.).

Module 5 – Azure Load Balancer

Characteristics

• Layer 4 (TCP/UDP).
• Distributes traffic across multiple backend VMs.
• Types:
  • Public: accepts Internet traffic (public frontend IP).
  • Internal: for internal traffic between tiers (e.g.: web tier → DB tier).

Health Probes

• Verifies if a backend VM is available.
• Types: HTTP, HTTPS, TCP.
• If a VM fails probes → no more traffic sent to it.

SKUs

Module 6 – Azure Application Gateway

Characteristics

• Layer 7 (HTTP/HTTPS): understands request content.
• SSL/TLS termination: decrypts HTTPS traffic, distributes as HTTP to backend.
• URL-based routing: /api/* → Pool 1, /static/* → Pool 2.
• WAF (Web Application Firewall): OWASP protection, SQL injections, XSS.

How It Works

Client
  ↓ HTTPS (SSL termination here)
Application Gateway (layer 7)
  ├── Rule: /api/* → Backend Pool 1 (API servers)
  ├── Rule: /static/* → Backend Pool 2 (Static servers)
  └── Rule: default → Backend Pool 3 (Web servers)

Load Balancer vs Application Gateway Comparison

Summary

Advanced Enrichment – Azure Networking In Depth

Section A – Virtual Networks (VNet): Advanced Concepts

A.1 Address Spaces and CIDR Notation

CIDR (Classless Inter-Domain Routing) notation defines the IP address range of a VNet.

Azure rule: the 5 reserved addresses per subnet are: network address, default gateway, two Azure DNS addresses, broadcast address.

CIDR Planning Example

Main VNet: 10.0.0.0/16 (65,536 addresses)
  ├── Subnet-Web     : 10.0.1.0/24  (251 hosts)
  ├── Subnet-App     : 10.0.2.0/24  (251 hosts)
  ├── Subnet-DB      : 10.0.3.0/24  (251 hosts)
  ├── Subnet-Mgmt    : 10.0.4.0/28  (11 hosts)
  ├── GatewaySubnet  : 10.0.255.0/27 (required for VPN/ER)
  └── AzureFirewallSubnet : 10.0.254.0/26 (required for Azure Firewall)

A.2 VNet Peering – Local and Global

Local Peering (same region)

• Minimal latency, traffic via Microsoft backbone.
• No network gateway required.
• Billing: low cost per GB transferred.

Global Peering (different regions)

• Example: Canada Central ↔ East US.
• Same Microsoft backbone, but slightly higher cost.
• Useful for multi-region high availability.

Non-transitivity of Peering

VNet-A ↔ VNet-B  (peered)
VNet-B ↔ VNet-C  (peered)
VNet-A ✗ VNet-C  (NO communication without direct peering)

To work around non-transitivity: use a central Hub VNet with User Defined Routes (UDR).

A.3 Service Endpoints vs Private Endpoints

When to Use Which?

• Service Endpoint: simplify access to Azure Storage from a VNet without exposing a public IP client-side.
• Private Endpoint: strict compliance (sensitive data, PCI-DSS, HIPAA), no desired public exposure.

A.4 DNS Configuration in a VNet

Azure offers three DNS resolution options:

# Associate a Private DNS Zone with a VNet
az network private-dns link vnet create \
  --resource-group MyRG \
  --zone-name "privatelink.blob.core.windows.net" \
  --name MyLink \
  --virtual-network MyVNet \
  --registration-enabled false

Section B – Network Security Groups (NSG): Deep Dive

B.1 NSG Rule Processing Flow

NSG rules are evaluated in priority order (smallest = processed first). As soon as a rule matches, processing stops.

Inbound packet
  │
  ▼
Subnet NSG?  →  Inbound rules of Subnet NSG (100 → 4096 → 65000-65500)
  │
  ▼
NIC NSG?  →  Inbound rules of NIC NSG
  │
  ▼
Delivery to VM

For outbound traffic, the order is reversed: NIC NSG first, then Subnet NSG.

B.2 Application Security Groups (ASG)

ASGs allow you to logically group VMs and write NSG rules based on these groups rather than IP addresses.

ASG-WebServers  → [VM-Web-01, VM-Web-02, VM-Web-03]
ASG-AppServers  → [VM-App-01, VM-App-02]
ASG-DBServers   → [VM-DB-01]

NSG rule with ASG:

{
  "name": "Allow-Web-to-App",
  "priority": 200,
  "direction": "Inbound",
  "access": "Allow",
  "protocol": "Tcp",
  "sourceApplicationSecurityGroups": ["ASG-WebServers"],
  "destinationApplicationSecurityGroups": ["ASG-AppServers"],
  "destinationPortRange": "8080"
}

Advantages: no need to update NSG rules when a VM is added — simply associate it with the ASG.

B.3 Effective Security Rules

The Effective Security Rules view in the Azure portal shows the combination of all applied NSG rules (subnet + NIC) for a given VM. Accessible via:

VM → Networking → Effective Security Rules

Very useful for debugging connectivity issues.

B.4 Most Important NSG Service Tags

Section C – Azure Load Balancer: Complete Reference

C.1 Load Balancer Architecture

Internet / Internal VNet
        │
        ▼
  ┌─────────────┐
  │  Frontend   │  ← Public or private IP
  │  (IP/Port)  │
  └──────┬──────┘
         │  Load Balancing Rule
         ▼
  ┌─────────────┐
  │  Backend    │  ← Pool of VMs or VMSS
  │    Pool     │
  └──────┬──────┘
         │  Health Probe
  ┌──────┴──────┐
  │  VM-01     VM-02     VM-03  │
  └────────────────────────────┘

C.2 Basic vs Standard SKU Comparison

Recommendation: always use the Standard SKU in production.

C.3 Health Probes

Key parameters:

• Interval: probe frequency (default 15 seconds).
• Unhealthy threshold: consecutive failures before exclusion (default 2).

C.4 Load Balancing Rules

A load balancing rule associates:

• Frontend IP + Port (e.g.: 80) → Backend Pool + Port (e.g.: 8080).
• Session persistence:
  • None: distribution by 5-tuple (src IP, src port, dst IP, dst port, protocol).
  • Client IP: sticky sessions based on source IP.
  • Client IP and Protocol: source IP + protocol.
• Floating IP (Direct Server Return): for SQL Always On Availability Groups.

C.5 Outbound Rules (Standard SKU only)

Allow controlling SNAT (Source Network Address Translation) for VMs without public IP:

# Create an outbound rule
az network lb outbound-rule create \
  --resource-group MyRG \
  --lb-name MyLB \
  --name OutboundRule1 \
  --frontend-ip-configs MyFrontendIP \
  --backend-pool-name MyBackendPool \
  --protocol All \
  --idle-timeout 4 \
  --outbound-ports 10000

Section D – Azure Application Gateway: Complete Guide

D.1 Application Gateway Architecture

Client HTTPS
      │
      ▼
┌─────────────────────────────────────────┐
│         Application Gateway             │
│                                         │
│  ┌─────────────┐   ┌──────────────────┐ │
│  │  Listener   │   │   WAF Engine     │ │
│  │ (port 443)  │   │ (OWASP 3.2)      │ │
│  └──────┬──────┘   └──────────────────┘ │
│         │                               │
│  ┌──────▼──────┐                        │
│  │   Rules     │                        │
│  │ /api/* → P1 │                        │
│  │ /img/* → P2 │                        │
│  │ default → P3│                        │
│  └──────┬──────┘                        │
└─────────┼───────────────────────────────┘
          │
    ┌─────┼──────┐
    ▼     ▼      ▼
   P1    P2     P3  (Backend Pools)

D.2 Key Components of Application Gateway

D.3 SSL/TLS Termination and End-to-End SSL

D.4 WAF (Web Application Firewall)

The Application Gateway WAF protects against common web attacks:

WAF Modes:

• Detection: logs without blocking (ideal for initial tuning).
• Prevention: blocks and logs malicious requests.

D.5 Multi-site Hosting

Allows hosting multiple websites on a single Application Gateway:

app.contoso.com  → Listener-1 → Backend Pool API
www.contoso.com  → Listener-2 → Backend Pool Web
api.fabrikam.com → Listener-3 → Backend Pool Fabrikam

Each listener uses a Host Header to distinguish domains.

D.6 Application Gateway SKUs

Section E – Azure DNS: Zones and Records

E.1 Public DNS vs Private DNS

E.2 DNS Record Types

E.3 Azure Private DNS – Auto-registration

When auto-registration is enabled on the VNet-Zone link, each VM created in the VNet automatically receives an A record in the private zone.

# Create a private DNS zone
az network private-dns zone create \
  --resource-group MyRG \
  --name "contoso.internal"

# Link the zone to the VNet with auto-registration
az network private-dns link vnet create \
  --resource-group MyRG \
  --zone-name "contoso.internal" \
  --name VNetLink1 \
  --virtual-network MyVNet \
  --registration-enabled true

E.4 Split-Horizon DNS

Split-horizon DNS returns different answers depending on whether the request comes from inside or outside the network:

From Internet:
  contoso.com → 20.10.5.100 (public IP)

From internal VNet:
  contoso.com → 10.0.1.10 (private IP)

Azure implementation: combine a public DNS zone (contoso.com) and a private DNS zone (contoso.com) linked to the VNet.

Section F – Azure VPN Gateway: Technical Reference

F.1 Operating Modes

F.2 Supported Protocols

F.3 Detailed VPN Gateway SKUs

The AZ SKUs (e.g.: VpnGw1AZ) add availability zone redundancy.

F.4 BGP (Border Gateway Protocol)

BGP enables dynamic routing between the on-premises network and Azure:

BGP advantages:

• Automatic route propagation (no manual static routes).
• Automatic failure detection and rerouting.
• Required for complex multi-site architectures.

BGP configuration:

# Enable BGP on the VPN Gateway
az network vnet-gateway create \
  --resource-group MyRG \
  --name MyVPNGateway \
  --vnet MyVNet \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1 \
  --asn 65000 \
  --bgp-peering-address 10.0.255.254

F.5 VNet-to-VNet vs Peering

Section G – Azure ExpressRoute: Dedicated Connectivity

G.1 ExpressRoute Architecture

On-premises datacenter
        │
        │  Dedicated fiber (via connectivity provider)
        ▼
  Peering Location (colocation)
        │
        │  Microsoft backbone (not Internet)
        ▼
  Microsoft Enterprise Edge (MSEE)
        │
        ▼
  Azure VNet (via ExpressRoute Gateway)

G.2 ExpressRoute Peering Types

Public Peering has been deprecated — replaced by Microsoft Peering.

G.3 ExpressRoute Circuit SKUs

G.4 ExpressRoute Global Reach

Allows connecting two on-premises networks to each other via the Microsoft backbone, without going through the Internet:

Paris Datacenter ──→ Microsoft Backbone ←── New York Datacenter
                            │
                        Azure VNet

Requires the Premium SKU or a peering agreement between the two connectivity providers.

G.5 ExpressRoute Direct

Direct connection to Microsoft edge routers (MSEE) without a third-party provider:

Section H – Azure Firewall: Managed Firewall

H.1 Azure Firewall Characteristics

Azure Firewall is a managed stateful firewall with high availability and automatic scaling.

H.2 Azure Firewall Rule Types

1. NAT Rules (DNAT)

Redirect incoming traffic from a public IP to a private IP:

firewall_public_ip:3389 → internal-VM:3389 (RDP)
firewall_public_ip:22   → internal-VM:22   (SSH)

2. Network Rules

Rules based on IP/port (layer 3/4):

Source: 10.0.1.0/24
Destination: 10.0.2.0/24
Protocol: TCP
Port: 1433 (SQL Server)
Action: Allow

3. Application Rules

Rules based on FQDNs and URLs (layer 7):

Source: 10.0.1.0/24
Target FQDN: *.microsoft.com
Protocol: HTTPS:443
Action: Allow

Predefined FQDN Tags: WindowsUpdate, MicrosoftActiveProtectionService, AppServiceEnvironment.

H.3 Azure Firewall SKUs

H.4 Integration with Azure Firewall Manager

Azure Firewall Manager allows centrally managing multiple Azure Firewalls via Firewall Policies (global and inherited local rules).

Global Firewall Policy (base rules)
  ├── Region A Policy (local rules)
  └── Region B Policy (local rules)

Section I – Azure Front Door and CDN

I.1 Azure Front Door

Azure Front Door is a global layer 7 load balancing and web application acceleration service.

I.2 Front Door vs Application Gateway Comparison

I.3 Azure Front Door SKUs

I.4 Azure CDN (Content Delivery Network)

Azure CDN distributes static content (images, CSS, JS, videos) from PoPs close to users.

CDN providers available in Azure:

How it works:

User (Paris)
      │
      ▼
  CDN PoP (Paris) → Cache HIT? Return content
      │                  No (Cache MISS)
      ▼
  Origin (Azure Storage / App Service / VM)

Section J – Network Watcher: Monitoring and Diagnostics

J.1 Network Watcher Tools

J.2 IP Flow Verify – Example

To test if inbound port 80 is allowed to a VM:

az network watcher test-ip-flow \
  --resource-group MyRG \
  --vm MyVM \
  --direction Inbound \
  --local 10.0.1.10:80 \
  --remote 203.0.113.1:12345 \
  --protocol TCP

Possible result:

• Access: Allow + RuleName: Allow-HTTP → traffic allowed by the indicated NSG rule.
• Access: Deny + RuleName: DenyAllInBound → blocked by the default deny rule.

J.3 NSG Flow Logs

NSG Flow Logs v2 record each network flow with:

• Source/destination IP, ports, protocol.
• Action (Allow/Deny).
• Bytes and packets transmitted.
• Direction (Inbound/Outbound).

They integrate with Azure Traffic Analytics (via Log Analytics) for visualizations and alerts.

# Enable NSG Flow Logs
az network watcher flow-log create \
  --resource-group MyRG \
  --name FlowLog-NSG1 \
  --nsg NSG1 \
  --storage-account MyStorageAccount \
  --enabled true \
  --format JSON \
  --log-version 2 \
  --retention 30

Section K – Hub-Spoke Architecture

K.1 Hub-Spoke Concept

The Hub-Spoke architecture is the reference pattern for enterprise Azure networks. It solves the non-transitivity problem of peering.

graph TB
    subgraph On-Premises
        DC[Datacenter]
        Users[Users]
    end

    subgraph Hub VNet ["Hub VNet (10.0.0.0/16)"]
        FW[Azure Firewall]
        VGW[VPN / ExpressRoute Gateway]
        BAS[Azure Bastion]
        DNS[DNS Resolver]
    end

    subgraph Spoke1 ["Spoke 1 – Production (10.1.0.0/16)"]
        Web1[Web Subnet]
        App1[App Subnet]
        DB1[DB Subnet]
    end

    subgraph Spoke2 ["Spoke 2 – Dev/Test (10.2.0.0/16)"]
        Web2[Web Subnet]
        App2[App Subnet]
    end

    subgraph Spoke3 ["Spoke 3 – Shared Services (10.3.0.0/16)"]
        AD[Active Directory]
        MON[Monitoring]
    end

    DC -->|ExpressRoute / VPN| VGW
    Users -->|VPN P2S| VGW
    VGW --> FW
    FW <-->|Peering| Spoke1
    FW <-->|Peering| Spoke2
    FW <-->|Peering| Spoke3

K.2 Traffic Flows in a Hub-Spoke Architecture

K.3 User Defined Routes (UDR)

UDRs allow overriding Azure’s default routing to force traffic through a network appliance (firewall, NVA).

Example: force Spoke traffic to Internet via Azure Firewall

# Create a route table
az network route-table create \
  --resource-group MyRG \
  --name RT-Spoke1

# Add a default route to Azure Firewall
az network route-table route create \
  --resource-group MyRG \
  --route-table-name RT-Spoke1 \
  --name DefaultToFirewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.0.4

# Associate the route table with the Spoke subnet
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name VNet-Spoke1 \
  --name Subnet-Web \
  --route-table RT-Spoke1

K.4 Shared Services in the Hub

The Hub typically hosts shared services accessible to all Spokes:

Section L – Complete Azure CLI Commands

L.1 VNet and Subnet Management

# Create a VNet with address space
az network vnet create \
  --resource-group MyRG \
  --name MyVNet \
  --address-prefixes 10.0.0.0/16 \
  --location eastus

# Create a subnet
az network vnet subnet create \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name SubnetWeb \
  --address-prefixes 10.0.1.0/24

# List VNets
az network vnet list --resource-group MyRG --output table

# Show VNet details
az network vnet show \
  --resource-group MyRG \
  --name MyVNet

# Create a peering (from VNet-A to VNet-B)
az network vnet peering create \
  --resource-group MyRG \
  --name VNet-A-to-B \
  --vnet-name VNet-A \
  --remote-vnet VNet-B \
  --allow-vnet-access true \
  --allow-forwarded-traffic true

# Enable Service Endpoints on a subnet
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name SubnetDB \
  --service-endpoints Microsoft.Storage Microsoft.Sql

L.2 NSG Management

# Create an NSG
az network nsg create \
  --resource-group MyRG \
  --name MyNSG

# Add an inbound rule (allow HTTP)
az network nsg rule create \
  --resource-group MyRG \
  --nsg-name MyNSG \
  --name Allow-HTTP \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes "*" \
  --source-port-ranges "*" \
  --destination-address-prefixes "*" \
  --destination-port-ranges 80

# Add an inbound rule (allow HTTPS)
az network nsg rule create \
  --resource-group MyRG \
  --nsg-name MyNSG \
  --name Allow-HTTPS \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes "*" \
  --source-port-ranges "*" \
  --destination-address-prefixes "*" \
  --destination-port-ranges 443

# Deny SSH traffic from Internet
az network nsg rule create \
  --resource-group MyRG \
  --nsg-name MyNSG \
  --name Deny-SSH-Internet \
  --priority 200 \
  --direction Inbound \
  --access Deny \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --source-port-ranges "*" \
  --destination-address-prefixes "*" \
  --destination-port-ranges 22

# Associate the NSG with a subnet
az network vnet subnet update \
  --resource-group MyRG \
  --vnet-name MyVNet \
  --name SubnetWeb \
  --network-security-group MyNSG

# List NSG rules
az network nsg rule list \
  --resource-group MyRG \
  --nsg-name MyNSG \
  --output table

L.3 Load Balancer Management

# Create a static Standard public IP
az network public-ip create \
  --resource-group MyRG \
  --name MyPublicIP \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

# Create a Standard public Load Balancer
az network lb create \
  --resource-group MyRG \
  --name MyLB \
  --sku Standard \
  --frontend-ip-name FrontendIP \
  --public-ip-address MyPublicIP \
  --backend-pool-name BackendPool

# Create an HTTP health probe
az network lb probe create \
  --resource-group MyRG \
  --lb-name MyLB \
  --name ProbeHTTP \
  --protocol Http \
  --port 80 \
  --path "/" \
  --interval 15 \
  --threshold 2

# Create a load balancing rule
az network lb rule create \
  --resource-group MyRG \
  --lb-name MyLB \
  --name LBRule-HTTP \
  --frontend-ip-name FrontendIP \
  --frontend-port 80 \
  --backend-pool-name BackendPool \
  --backend-port 80 \
  --protocol Tcp \
  --probe-name ProbeHTTP \
  --idle-timeout 4

# Add a VM to the backend pool (via NIC)
az network nic ip-config address-pool add \
  --resource-group MyRG \
  --nic-name MyVM-NIC \
  --ip-config-name ipconfig1 \
  --lb-name MyLB \
  --address-pool BackendPool

L.4 Public IP Management

# Create a Basic dynamic public IP
az network public-ip create \
  --resource-group MyRG \
  --name DynamicIP \
  --sku Basic \
  --allocation-method Dynamic

# Create a Standard static zone-redundant public IP
az network public-ip create \
  --resource-group MyRG \
  --name StaticIP \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3 \
  --dns-name mywebapp

# List all public IPs
az network public-ip list \
  --resource-group MyRG \
  --output table

# Show allocated IP address
az network public-ip show \
  --resource-group MyRG \
  --name StaticIP \
  --query "ipAddress" \
  --output tsv

L.5 Network Watcher – Diagnostics

# Enable Network Watcher in a region
az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled true

# Check if an NSG flow is allowed or blocked
az network watcher test-ip-flow \
  --resource-group MyRG \
  --vm MyVM \
  --direction Inbound \
  --local 10.0.1.10:80 \
  --remote 0.0.0.0:65000 \
  --protocol TCP

# Identify the next routing hop
az network watcher show-next-hop \
  --resource-group MyRG \
  --vm MyVM \
  --source-ip 10.0.1.10 \
  --dest-ip 8.8.8.8

# Start a packet capture (5 minutes)
az network watcher packet-capture create \
  --resource-group MyRG \
  --vm MyVM \
  --name CaptureTest \
  --storage-account MyStorageAccount \
  --time-limit 300

L.6 Azure Firewall

# Create AzureFirewallSubnet (required, this exact name)
az network vnet subnet create \
  --resource-group MyRG \
  --vnet-name HubVNet \
  --name AzureFirewallSubnet \
  --address-prefixes 10.0.254.0/26

# Create a public IP for the Firewall
az network public-ip create \
  --resource-group MyRG \
  --name FW-IP \
  --sku Standard \
  --allocation-method Static

# Create Azure Firewall
az network firewall create \
  --resource-group MyRG \
  --name MyFirewall \
  --location eastus \
  --sku AZFW_VNet \
  --tier Standard

# Configure IP on the firewall
az network firewall ip-config create \
  --resource-group MyRG \
  --firewall-name MyFirewall \
  --name FW-ipconfig \
  --public-ip-address FW-IP \
  --vnet-name HubVNet

# Add a network rule
az network firewall network-rule create \
  --resource-group MyRG \
  --firewall-name MyFirewall \
  --collection-name NetRules \
  --priority 200 \
  --action Allow \
  --name Allow-DNS \
  --protocols UDP \
  --source-addresses 10.0.0.0/8 \
  --destination-addresses 8.8.8.8 8.8.4.4 \
  --destination-ports 53

# Add an application rule (FQDN)
az network firewall application-rule create \
  --resource-group MyRG \
  --firewall-name MyFirewall \
  --collection-name AppRules \
  --priority 300 \
  --action Allow \
  --name Allow-Microsoft \
  --source-addresses 10.0.0.0/8 \
  --protocols https=443 \
  --fqdn-tags WindowsUpdate MicrosoftActiveProtectionService

Section M – Review Questions

Q1 – What is the minimum number of IP addresses available for hosts in a /29 subnet in Azure?

Answer: A /29 contains 8 total addresses. Azure reserves 5 addresses (network, gateway, 2×DNS, broadcast). This leaves 3 usable addresses for hosts.

Q2 – What is the main difference between a Service Endpoint and a Private Endpoint for Azure Storage?

Answer: A Service Endpoint routes traffic to the public IP of Azure Storage via the Microsoft backbone (the service’s public IP is retained). A Private Endpoint assigns a private IP in your VNet to the service, making it completely inaccessible from the Internet. The Private Endpoint is more secure and recommended for sensitive data.

Q3 – Why is VNet Peering said to be “non-transitive” and how can you work around it?

Answer: If VNet-A is peered with VNet-B, and VNet-B is peered with VNet-C, resources in VNet-A cannot communicate directly with those in VNet-C. To work around this limitation, use a Hub-Spoke architecture: a central Hub VNet is peered with all Spokes, and User Defined Routes (UDR) force inter-Spoke traffic to transit through an Azure Firewall or NVA in the Hub.

Q4 – What is the difference between Azure Load Balancer Basic and Standard SKUs?

Answer: Key differences are:

• Standard supports availability zones (zone-redundant), Basic does not.
• Standard can handle up to 1000 backend instances vs 300 for Basic.
• Standard has a 99.99% SLA, Basic has no SLA.
• Standard is closed by default (NSG required), Basic is open.
• Standard supports Outbound Rules for SNAT, Basic does not.

Q5 – In what scenario would you choose Azure ExpressRoute over Azure VPN Gateway?

Answer: ExpressRoute is preferred when:

1. Required bandwidth exceeds what a VPN can offer (>2.5 Gbps).
2. Consistent latency is critical (financial trading, real-time).
3. Regulatory compliance requires data not to transit through the Internet.
4. Massive data migrations are planned.
5. A 99.95% SLA is contractually required.

Q6 – How does the WAF in Azure Application Gateway work and what types of attacks does it block?

Answer: The Application Gateway WAF uses OWASP CRS (Core Rule Set) v3.2 rules to analyze HTTP/HTTPS traffic before it reaches the backend servers. It operates in two modes: Detection (logs without blocking) and Prevention (blocks and logs). It protects against: SQL injections, XSS (cross-site scripting) attacks, path traversal, HTTP protocol violations, and request smuggling.

Q7 – What is the difference between an A DNS record and a CNAME, and when to use each?

Answer:

• CNAME record: maps a name to another name (alias). Used to point to another FQDN (e.g.: mail.contoso.com → mailserver.contoso.com). A CNAME cannot be at the domain root (apex) — for that case, use an Alias Record or ANAME.

Q8 – What is BGP in the context of Azure VPN Gateway and why is it useful?

Answer: BGP (Border Gateway Protocol) is a dynamic routing protocol. In the context of Azure VPN Gateway, it enables:

• Automatic route propagation between the on-premises network and Azure, without manual static routes.
• Automatic failure detection and traffic rerouting.
• Managing complex multi-site architectures with multiple VPN connections.
• Coexistence with ExpressRoute (VPN as a backup path).

Q9 – What Azure CLI command would you use to diagnose why a VM cannot receive HTTP traffic?

Answer:

# Check if HTTP flow (port 80) is allowed by NSGs
az network watcher test-ip-flow \
  --resource-group MyRG \
  --vm MyVM \
  --direction Inbound \
  --local 10.0.1.10:80 \
  --remote 0.0.0.0:65000 \
  --protocol TCP

If the result indicates Deny with a rule name, you can identify exactly which NSG rule is blocking traffic. You can also use az network watcher show-next-hop to verify routing, or consult the VM’s Effective Security Rules in the portal.

Q10 – What is the role of Azure Front Door compared to Azure Application Gateway, and when to choose one over the other?

Answer:

• Azure Application Gateway is a regional layer 7 load balancer: it distributes traffic between multiple servers within a single Azure region. Ideal for applications hosted in a single region.
• Azure Front Door is a global layer 7 load balancer: it distributes traffic between origins in multiple Azure regions via the Microsoft global network (Anycast). It additionally offers an integrated CDN for caching static content.

Choose Application Gateway when: single region, regional WAF needed, local SSL termination. Choose Front Door when: multi-region application, CDN, geographic resilience, reduced latency for global users.

Extended Final Summary

Advanced Section – Review Questions and Glossary

Review Questions – Azure Networking

Question 1 You have two VNets in different regions: East US and West Europe. Applications in these VNets must communicate directly without going through the Internet. Which solution do you use?

• A) VNet Peering (Global VNet Peering)
• B) VPN Gateway (Site-to-Site)
• C) ExpressRoute
• D) Azure Front Door

Answer: A — Global VNet Peering connects VNets in different regions with very low latency using the private Microsoft backbone. Traffic never goes through the Internet and does not require a gateway (unlike VPN).

Question 2 Your web application on App Service needs to call an API in a private VNet without exposing this API on the Internet. Which Azure service allows the App Service (public PaaS service) to access the private VNet?

• A) Service Endpoints
• B) VNet Integration (App Service VNet Integration)
• C) Private Link
• D) Azure Firewall

Answer: B — VNet Integration allows an App Service (PaaS) to access resources in a private VNet via an outbound connection. Private Endpoint is for accessing PaaS services from the VNet (reverse direction).

Question 3 Your team deploys an NSG and wants to understand which rules are applied to a specific VM (combination of subnet NSG + NIC NSG). Which tool provides a consolidated view of all effective rules?

• A) Azure Policy Compliance
• B) Network Watcher → Effective Security Rules
• C) Azure Firewall → Rule logs
• D) Azure Monitor → Network Insights

Answer: B — Network Watcher → Effective Security Rules displays the consolidated and sorted list of all effective NSG rules applied to a VM’s network interface (combining subnet NSG + NIC NSG).

Question 4 What is the fundamental difference between Azure Load Balancer (Standard) and Azure Application Gateway?

• A) Load Balancer works at level 4 (TCP/UDP); Application Gateway works at level 7 (HTTP/HTTPS) with WAF and URL-based routing
• B) Application Gateway is free; Load Balancer is paid
• C) Load Balancer supports HTTPS; Application Gateway only supports HTTP
• D) Application Gateway is for VMs; Load Balancer is for containers

Answer: A — Standard Load Balancer operates at layer 4 (transport): distributes TCP/UDP without inspecting content. Application Gateway operates at layer 7 (application): understands HTTP/HTTPS, can route by URL path, offer SSL termination and WAF.

Question 5 Your organization has an on-premises datacenter. It requires a private, dedicated connection to Azure with guaranteed bandwidth of 10 Gbps and a latency SLA. Which solution is appropriate?

• A) VPN Gateway with VpnGw5 SKU
• B) Azure ExpressRoute
• C) Azure Front Door
• D) VNet Peering

Answer: B — ExpressRoute provides a private, dedicated connection (not via Internet) between the on-premises datacenter and Azure, with bandwidths from 50 Mbps to 100 Gbps and guaranteed availability SLAs. VPN Gateway goes through the Internet.

Question 6 A developer is trying to SSH (port 22) into a production Azure VM. The connection fails. Which Zero Trust approach is recommended to grant temporary SSH access without permanently exposing port 22?

• A) Open port 22 in the NSG permanently
• B) Use JIT VM Access (Microsoft Defender for Cloud) to temporarily open port 22 on demand
• C) Install an SSH tunnel via Azure Bastion
• D) Both B and C are valid (different approaches)

Answer: D — JIT VM Access (Defender for Cloud) temporarily opens the SSH/RDP port in the NSG with a timer. Azure Bastion provides SSH/RDP access via the browser without exposing any public ports. Both are valid and complementary Zero Trust approaches.

Glossary – Azure Networking

Search Terms

azure · fundamentals · networking · core · infrastructure · microsoft · gateway · application · expressroute · network · peering · skus · dns · firewall · load · nsg · rules · vnet · vpn · architecture · balancer · door · front · types