Topic 1 of 23Module 1 — Getting Started

Module 1 — Getting Started

Introduction to Cloud Computing & Microsoft Azure

Microsoft Azure is a public cloud platform. Instead of buying and running your own servers, you rent computing power, storage, networking and higher-level services from Microsoft's global datacenters — and pay only for what you actually use.

Why organizations move to the cloud

💰

CapEx → OpEx

No big upfront hardware purchase. You rent capacity monthly and treat it as an operating expense.

📈

Elastic scale

Add capacity for a traffic spike, then remove it an hour later. You're never sized for the worst case year-round.

🌍

Global reach

Deploy close to your users in dozens of countries without building a single datacenter.

🛡️

Built-in resilience

Redundant power, cooling and networking, plus replication options, come as part of the platform.

Try it: who manages what?

Cloud computing comes in three flavors — IaaS, PaaS and SaaS — and the only real difference is how much of the stack you manage yourself versus how much Azure manages for you. Click each one and watch the stack change.

Data & Applications
Runtime
Operating System
Servers & Virtualization
Networking
Datacenter
You manage Azure manages

The shared responsibility model

A common exam topic. No matter which service model you pick, some things are always yours and some are always Microsoft's:

🔑

Always yours

Your data, your user accounts and access rights, and the devices people connect from.

🏢

Always Microsoft's

Physical hosts, physical network and the physical datacenter itself.

Cloud deployment models

☁️
Public Shared Azure infrastructure
🏠
Private Dedicated to one organization
🔗
Hybrid On-premises + cloud combined

How you manage Azure

🌐

Azure Portal

A web UI for clicking through resource creation and configuration.

⌨️

CLI & PowerShell

Command-line tools for scripting repeatable actions.

🏗️

ARM & Bicep

Infrastructure as code, so environments can be version-controlled and redeployed.

💡

Everything you create in Azure — a VM, a database, a web app — is called a resource, and every resource lives inside a resource group. That single idea underpins almost all of Azure's structure, and it's the subject of the next lesson.

Module 1 — Getting Started

Azure Portal, Regions & Resource Groups

Before you deploy anything, you need to understand three things: where your resources physically live (regions), how they're organized (resource groups), and how the whole account structure fits together.

Azure's physical hierarchy

You never pick a datacenter directly. You pick a region, and Azure decides which underlying buildings host your resources.

🏢
Datacenter A physical building
🛡️
Availability Zone Isolated power & cooling
📍
Region What you actually pick
🌍
Geography Country / legal boundary

Choosing a region

Latency

Pick a region physically close to the users who'll be hitting it.

🧩

Service availability

Not every Azure service exists in every region — check before you design around one.

⚖️

Compliance

Some data is legally required to stay inside a specific geography.

💵

Pricing

The same VM size can cost noticeably more in one region than another.

⚠️

Not every region has Availability Zones. If zone-level resiliency matters to your design, confirm the target region supports zones before you build on top of it.

Region pairs

Most regions are paired with another region at least 300 miles away in the same geography — for example Central IndiaSouth India. During a broad outage Azure prioritizes restoring one region of each pair first, and several services replicate across the pair automatically for disaster recovery.

The management hierarchy

Separately from the physical hierarchy above, there's an organizational hierarchy that controls billing and permissions:

🏛️
Management Group Policy across subscriptions
💳
Subscription Billing & quota boundary
📦
Resource Group Logical container
🖥️
Resource The actual VM, DB, app

Resource groups in practice

A resource group is a logical container holding related resources — a VM together with its disk, network interface and public IP. A few rules worth memorizing:

1️⃣

Exactly one group

Every resource belongs to one resource group — never zero, never two.

🌐

Groups can span regions

A group has its own location (for metadata), but resources inside it can live in different regions.

🔄

Resources can move

You can move most resources between groups or subscriptions later.

🗑️

Deleting cascades

Deleting a resource group permanently deletes everything inside it.

⚠️

Because deleting a resource group is permanent and cascades to every resource inside, always double-check its contents before confirming. Use resource locks on production groups to prevent accidents.

Navigating the Azure Portal

🔍

Global search

The fastest way to reach any service or resource — faster than the menus.

Favorites

Pin the services you use daily to the left sidebar.

📊

Dashboards

Build custom tile views per project or environment, and share them with your team.

⌨️

Cloud Shell

A browser-based Bash or PowerShell terminal, already authenticated as you.

Tagging

Tags are simple name:value labels you attach to resources — for example Environment:Production, Owner:Finance, CostCenter:4412. They don't change how a resource behaves, but they're what makes cost reports and bulk governance actually usable at scale.

💡

A practical naming convention pays for itself fast. Something like rg-projectname-env-region (e.g. rg-shop-prod-cin) tells you what a group is for at a glance, six months later.

Module 1 — Getting Started

Module 1 Exam

Eight questions covering cloud service models, the shared responsibility model, regions and resource groups. Instant feedback after each answer, then a final score. Aim for 70% or better before moving on.

Module 2 — Compute

Create and Manage Azure Virtual Machines

A virtual machine is Azure's classic IaaS offering: a full computer — CPU, memory, disk, network card — running on Microsoft's hardware, where you control the operating system and everything installed on it.

When a VM is the right choice

Choose a VM when…

You need full OS control, must install specific software, are migrating a legacy app as-is, or need a custom kernel/driver.

🚫

Prefer PaaS when…

You just want to run a web app or API. App Service or Functions remove the patching and scaling burden entirely.

💡

Rule of thumb: the more control you need over the operating system, the more a VM makes sense. The less you want to manage, the further up the PaaS/serverless stack you should go.

What gets created alongside your VM

Creating one VM actually creates several linked resources. Deleting the VM does not automatically delete all of them — a very common source of surprise costs.

🖥️
Virtual Machine The compute itself
💾
OS Disk Managed disk
🔌
NIC Network interface
🌐
Public IP Optional
🛡️
NSG Firewall rules

VM size families

Azure groups VM sizes into families optimized for different workloads. The letter tells you the purpose:

FamilyOptimized forTypical use
B-seriesBurstable, low costDev/test, low-traffic sites that occasionally spike
D-seriesGeneral purposeMost production workloads, web servers, small databases
E-seriesMemory optimizedIn-memory caching, large relational databases
F-seriesCompute optimizedBatch processing, application servers, analytics
L-seriesStorage optimizedBig data, NoSQL, high disk throughput
N-seriesGPUMachine learning, rendering, visualization

Creating a VM in the portal

The creation wizard walks through tabs. The decisions that actually matter:

📋

Basics

Subscription, resource group, VM name, region, image (Windows/Linux), size, and admin credentials.

💾

Disks

OS disk type (Premium SSD, Standard SSD, HDD) and any extra data disks.

🔗

Networking

Virtual network, subnet, public IP, and which inbound ports to open.

⚙️

Management

Boot diagnostics, auto-shutdown schedules, backup and patch settings.

The same thing with the CLI is a single command:

az vm create \
  --resource-group rg-lab-prod-cin \
  --name web-vm-01 \
  --image Ubuntu2204 \
  --size Standard_D2s_v3 \
  --admin-username azureuser \
  --generate-ssh-keys

Connecting to your VM

MethodOSPortNotes
RDPWindows3389Graphical desktop session
SSHLinux22Key-based auth strongly preferred over passwords
Azure BastionBothBrowser-based, no public IP or open port needed
Serial ConsoleBothWorks even when networking is broken
⚠️

Never leave RDP (3389) or SSH (22) open to the whole internet on a production VM. Use Azure Bastion, or restrict the NSG rule to your office IP, or enable just-in-time VM access so the port opens only when requested.

VM power states and what you pay for

StateCompute chargesStorage charges
RunningYesYes
Stopped (from inside the OS)Yes — still allocatedYes
Stopped (deallocated)NoYes
DeletedNoOnly for disks you kept
⚠️

This catches people out constantly: shutting a VM down from inside Windows or Linux leaves it allocated, and you keep paying for compute. To actually stop billing, use Stop (deallocate) from the portal or az vm deallocate.

Common troubleshooting

🔌

Can't connect via RDP/SSH

Check the NSG allows your IP on the right port, the VM is running (not deallocated), and it has a reachable IP.

🐌

VM is slow

Check CPU/memory metrics in Monitor. Often it's disk — a Standard HDD on a busy workload is a frequent culprit.

🔄

Won't boot

Use boot diagnostics for a screenshot of the console, or the serial console to fix it from inside.

ℹ️

A single VM has no high-availability guarantee. To get an SLA you need at least two VMs across an availability set or, better, availability zones — covered when we reach scale sets later in this module.

Module 2 — Compute

Azure VM Disks & Core Architecture

Disk choice is where VM performance is won or lost — and where a surprising share of the bill comes from. This lesson covers the three disk roles, the four performance tiers, and how resiliency options fit together.

The three disks attached to a VM

💿

OS disk

Holds the operating system. Always present, persistent, labelled C: on Windows or mounted at / on Linux.

🗄️

Data disk(s)

Optional, persistent storage for your application data and databases. Attach as many as the VM size allows.

Temporary disk

Local SSD on the physical host. Fast, but wiped on deallocation or host maintenance.

⚠️

Never store anything you care about on the temporary disk (usually D: on Windows, /dev/sdb on Linux). It's designed for page files, swap and scratch data only — Azure will wipe it without warning.

Managed disk performance tiers

TierBacked byBest forRelative cost
Ultra DiskNVMe SSDSAP HANA, top-tier databases needing sub-ms latencyHighest
Premium SSDSSDProduction workloads — the safe defaultHigh
Standard SSDSSDWeb servers, light production, dev/testMedium
Standard HDDSpinning diskBackups, archives, infrequent accessLowest
ℹ️

Only Premium SSD and above qualify for the single-instance VM SLA. If a workload matters, Standard HDD is a false economy — the performance hit usually costs more in wasted compute than the disk saves.

Managed vs unmanaged disks

Modern Azure uses managed disks exclusively for new deployments. Azure handles the underlying storage accounts, replication and scaling for you — you just say "I want a 256 GB Premium SSD." Unmanaged disks (where you managed your own storage accounts) are legacy and shouldn't be used for anything new.

Disk encryption

🔒

SSE — Storage Service Encryption

On by default for every managed disk, at no cost. Encrypts data at rest on the platform side.

🔑

ADE — Azure Disk Encryption

Uses BitLocker (Windows) or DM-Crypt (Linux) inside the guest OS, with keys held in Azure Key Vault.

Snapshots and images

ConceptWhat it capturesUsed for
SnapshotA point-in-time copy of one diskBackup before a risky change; cloning a single disk
ImageA whole generalized VM (OS + data disks)A reusable template for deploying many identical VMs
💡

Before you deploy from a custom image, the source VM must be generalized (sysprep on Windows, waagent -deprovision on Linux). Skipping this produces VMs with duplicate machine identities that misbehave on the network.

Resiliency: how VMs stay available

OptionProtects againstSLA
Single VM (Premium SSD)Nothing structural99.9%
Availability Set (2+ VMs)Rack & host failure, planned maintenance99.95%
Availability Zones (2+ VMs)An entire datacenter failing99.99%

Fault domains and update domains

These two terms are what an availability set actually does, and they're a reliable exam question:

🔌

Fault domain

A group of hardware sharing a power source and network switch. Spreading VMs across fault domains survives a rack failure.

🔄

Update domain

A group rebooted together during planned maintenance. Spreading across update domains means patching never takes everything down at once.

ℹ️

Availability sets keep all VMs inside a single datacenter — so they don't protect against that whole datacenter going down. Availability zones spread VMs across physically separate buildings, which is why they carry the higher 99.99% SLA.

💡

Use zones when your region supports them and resiliency matters. Fall back to an availability set in regions without zone support, or when cross-zone network latency would hurt a chatty application.

Module 2 — Compute

Virtual Machine Scale Sets & Auto Scaling

A Virtual Machine Scale Set (VMSS) manages a group of identical VMs as a single resource — and grows or shrinks that group automatically based on demand. It's how you stop paying for peak capacity 24 hours a day.

Scaling up vs scaling out

⬆️

Scale up (vertical)

Replace one VM with a bigger one. Simple, but requires a restart and has a hard ceiling.

➡️

Scale out (horizontal)

Add more identical VMs. No downtime, and virtually unlimited — this is what VMSS does.

Try it: watch autoscale react

This scale set is configured to scale out above 70% CPU and scale in below 30%, with a minimum of 2 and a maximum of 8 instances. Drag the slider to simulate changing load.

45%

Scale out > 70%  ·  Scale in < 30%  ·  Min 2  ·  Max 8

⚖️ Load is in the healthy range — instance count is stable.

How a scale set is defined

📋

A single model

One image, size and configuration is applied to every instance — they're deliberately identical.

🔢

Instance limits

A minimum (your always-on floor) and maximum (your cost ceiling).

⚖️

Load balancer

Traffic is distributed across instances automatically as they come and go.

📏

Scaling rules

Metric, threshold, direction, instance change and cooldown period.

Autoscale rule anatomy

SettingExampleWhat it means
MetricPercentage CPUWhat's measured. Can also be memory, queue length or a custom metric.
Operator + thresholdGreater than 70The trigger point.
Duration10 minutesHow long it must stay past the threshold — prevents reacting to brief spikes.
ActionIncrease count by 2How many instances to add or remove.
Cool-down5 minutesWait before the rule can fire again, so instances have time to warm up.
⚠️

Always pair a scale-out rule with a matching scale-in rule. A scale set that only grows will happily sit at maximum capacity — and maximum cost — forever.

💡

Set your scale-in threshold well below scale-out (e.g. out at 70%, in at 30%, not 65%). If they're too close you get flapping — instances added and removed repeatedly, which is both slow and expensive.

Scaling modes

Manual

You set the instance count yourself. Fine for predictable, steady workloads.

📊

Metric-based

Reacts to live CPU, memory or custom metrics. The general-purpose choice.

🗓️

Schedule-based

Scale up every weekday at 8am, down at 8pm. Ideal for known business-hours patterns.

Upgrade policies

PolicyBehaviour
AutomaticAll instances updated at once. Fastest, but causes downtime.
RollingUpdated in batches with health checks between. The safe production choice.
ManualNothing changes until you upgrade each instance yourself.

Creating a scale set from the CLI:

az vmss create \
  --resource-group rg-lab-prod-cin \
  --name web-vmss \
  --image Ubuntu2204 \
  --instance-count 2 \
  --vm-sku Standard_D2s_v3 \
  --upgrade-policy-mode rolling \
  --admin-username azureuser \
  --generate-ssh-keys
ℹ️

VMSS suits workloads where any instance can be destroyed and replaced without losing data — web front ends, API tiers, batch workers. It's a poor fit for stateful single-instance apps like a primary database server, which should keep its data on persistent managed disks instead.

Module 2 — Compute

Module 2 Exam

Ten questions on virtual machines, disks, availability and scale sets. Instant feedback after each answer, then a final score. Aim for 70% or better before moving on.

Module 3 — Storage

Introduction to Azure Storage Accounts

A storage account is the container that holds all your Azure storage data services. It provides a unique namespace, and every blob, file share, queue and table lives inside one.

The four data services

🗂️

Blob

Unstructured objects — images, video, backups, logs. The most-used service by far.

📁

File

Fully managed SMB/NFS file shares you can mount like a network drive.

📬

Queue

Simple message store for decoupling application components.

🗃️

Table

NoSQL key-value store for large volumes of structured, non-relational data.

Account types

TypeSupportsUse when
Standard general-purpose v2All four services, all tiersThe default recommendation for almost everything
Premium block blobsBlob onlyHigh transaction rates, low latency needs
Premium file sharesFiles onlyEnterprise file shares needing SSD performance
Premium page blobsPage blobsUnmanaged VM disks (legacy)

Redundancy — the most-tested topic

Redundancy decides how many copies of your data exist and where. Every option keeps at least three copies.

OptionCopiesSpread acrossSurvives
LRS — Locally redundant3One datacenterDisk/rack failure
ZRS — Zone redundant3Three availability zonesA datacenter failing
GRS — Geo redundant6Primary (LRS) + paired regionA whole region failing
GZRS — Geo-zone redundant6Primary (ZRS) + paired regionBoth, highest durability
ℹ️

The RA- prefix (RA-GRS, RA-GZRS) means read access: you can read from the secondary region at any time. Without it, the secondary is only reachable after Microsoft initiates a failover.

Access tiers for blob data

TierStorage costAccess costMinimum stay
HotHighestLowestNone
CoolLowerHigher30 days
ColdLower stillHigher still90 days
ArchiveLowestHighest + rehydration delay180 days
⚠️

Archive is offline. Reading data requires rehydration, which can take hours. It's for compliance archives you almost never touch — not for backups you might need in a hurry.

💡

Use lifecycle management policies to move blobs down the tiers automatically — for example Hot → Cool after 30 days, Cool → Archive after 180. It's the single easiest storage cost saving available.

Securing access

🔑

Access keys

Two keys giving full control. Powerful and risky — rotate regularly, never embed in client apps.

🎫

SAS tokens

Time-limited URLs scoped to specific permissions and resources. The right choice for sharing.

👤

Entra ID + RBAC

Identity-based access with roles like Storage Blob Data Reader. The most secure option.

🌐

Network rules

Firewall the account to specific VNets or IP ranges, or use a private endpoint.

Creating an account from the CLI:

az storage account create \
  --resource-group rg-lab-prod-cin \
  --name veplearnstorage01 \
  --location centralindia \
  --sku Standard_ZRS \
  --kind StorageV2 \
  --access-tier Hot
⚠️

Storage account names must be globally unique across all of Azure, 3–24 characters, lowercase letters and numbers only. No hyphens — a common source of failed deployments.

Module 3 — Storage

Azure Blob Storage & File Storage

Blob and File are the two storage services you'll use most. They solve different problems: blobs are for objects your application reads and writes, file shares are for drives your servers and users mount.

Blob storage structure

🏦
Storage Account Unique namespace
📦
Container Like a top-level folder
📄
Blob The actual file

A blob's URL follows a predictable pattern:

https://veplearnstorage01.blob.core.windows.net/images/logo.png
       └── account ──┘                          └container┘└ blob ┘

The three blob types

TypeOptimized forTypical use
Block blobReading whole objectsImages, documents, video, backups — the default
Append blobAdding to the endLog files, audit trails, telemetry
Page blobRandom read/writeVirtual hard disks (VHDs)

Container access levels

🔒

Private

No anonymous access. Credentials required for everything. The safe default.

📄

Blob

Anonymous read of individual blobs if you know the exact URL, but the container can't be listed.

📂

Container

Anonymous read and listing — anyone can enumerate every file. Use with real caution.

⚠️

Public container access is behind a documented history of data leaks. Prefer private containers with SAS tokens or Entra ID. Azure now lets you disable anonymous access at the account level — turn it on for anything sensitive.

Blob data protection

🕑

Soft delete

Deleted blobs are recoverable for a retention window you set. Protects against accidents.

📚

Versioning

Every write creates a new version, so you can roll back to any earlier state.

📸

Snapshots

Manual read-only point-in-time copies of a single blob.

🔐

Immutability

WORM policies that block modification or deletion for a legally-defined period.

Azure Files

Azure Files gives you a fully managed network file share, reachable over SMB (Windows/Linux/macOS) or NFS (Linux, premium only). Unlike blobs, applications need no rewriting — it mounts as a normal drive.

🖥️

Lift-and-shift

Move a legacy app that expects a UNC path without changing its code.

🤝

Shared config

Several VMs reading the same configuration or content directory.

🔄

Azure File Sync

Cache the share on on-premises Windows Servers, with the cloud as the source of truth.

Mounting a share on Linux:

sudo mount -t cifs \
  //veplearnstorage01.file.core.windows.net/appdata /mnt/appdata \
  -o vers=3.0,username=veplearnstorage01,password=<key>,serverino

Blob vs Files — choosing

Blob StorageAzure Files
AccessREST API / SDKMounted drive (SMB/NFS)
StructureFlat, with virtual foldersTrue hierarchical folders
Best forApp-managed objects, static contentShared drives, legacy apps
App changesCode must use the SDKNone — it's just a path
💡

Quick rule: if your application code reads the data, use Blob. If an operating system or user needs to browse it like a folder, use Files.

ℹ️

Blob storage has no real folders. A blob named 2024/reports/q1.pdf is one flat name containing slashes — tools just display it as a tree. This is why "renaming a folder" means copying every blob underneath it.

Module 3 — Storage

Azure Queue Storage & Table Storage

The two remaining storage services are less flashy but solve real architectural problems: queues decouple components so they can fail independently, and tables store huge volumes of structured data cheaply.

Why queues exist

Without a queue, a web app that resizes uploaded images must do it while the user waits — and if the resizer crashes, the request is lost. A queue turns that into a durable hand-off:

🌐
Web App Accepts upload, replies instantly
📬
Queue Message waits durably
⚙️
Worker Processes when ready
🔗

Decoupling

Producer and consumer never talk directly, so either can be down without losing work.

📊

Load levelling

A traffic spike grows the queue, not your error rate. Workers drain it at their own pace.

📈

A scaling signal

Queue length is an excellent autoscale metric — far better than CPU for worker tiers.

How a message is consumed

Queue Storage doesn't delete a message when it's read. Instead it becomes invisible for a set time while the worker processes it:

StepWhat happens
1. Get messageWorker receives it; it becomes invisible to other workers
2. ProcessWorker does the job within the visibility timeout
3. DeleteWorker explicitly deletes the message on success
If the worker crashesThe timeout expires, the message reappears, another worker retries it
ℹ️

This design means delivery is at-least-once, not exactly-once — a message can be processed twice if a worker is slow. Make your processing idempotent so a repeat run causes no harm.

⚠️

Queue Storage limits: messages max 64 KB and live at most 7 days by default. For large payloads, store the file in blob storage and put only its URL in the message.

Queue Storage vs Service Bus

Queue StorageService Bus Queues
ComplexityVery simpleFeature-rich
Message size64 KBUp to 100 MB (premium)
OrderingNot guaranteedFIFO with sessions
ExtrasTopics, dead-letter, transactions, duplicate detection
Choose whenSimple work hand-off, huge volume, lowest costEnterprise messaging, ordering or pub/sub needed

Table Storage

Table Storage is a NoSQL key-value store: schemaless rows (entities) that can each carry different properties. It's very cheap and scales to billions of rows, but it is not a relational database — no joins, no foreign keys, no complex queries.

The two keys that decide everything

🗂️

PartitionKey

Groups related entities and determines which physical partition stores them.

🔑

RowKey

Uniquely identifies an entity within its partition.

Together they form the primary key. A query supplying both is a point lookup — the fastest operation available. Supplying neither forces a full table scan.

Query suppliesPerformance
PartitionKey + RowKeyFastest — direct point query
PartitionKey + a range of RowKeysFast — scans one partition
RowKey onlySlow — scans every partition
NeitherSlowest — full table scan
💡

Design your PartitionKey around how you'll query, not how the data naturally groups. For per-customer lookups use CustomerId; for time-series use something like 2026-08. Getting this wrong is the number-one cause of slow Table Storage.

ℹ️

For new projects, Microsoft generally steers people to Azure Cosmos DB for Table — the same API with global distribution, guaranteed low latency and secondary indexes. We cover Cosmos DB in Module 9.

Module 3 — Storage

Module 3 Exam

Ten questions on storage accounts, redundancy, access tiers, blobs, files, queues and tables. Aim for 70% or better before moving on.

Module 4 — Networking

Introduction to Azure Virtual Networks

A Virtual Network (VNet) is your own private, isolated slice of the Azure network. It's the foundation everything else sits on — VMs, databases, app services with private access all attach to a VNet.

What a VNet gives you

🔒

Isolation

Your VNet is invisible to every other customer, even on shared physical hardware.

🔢

Your own IP space

You choose the private address range and how it's divided.

🔗

Connectivity

Link to other VNets (peering) or to your office (VPN / ExpressRoute).

🛡️

Traffic control

NSGs, route tables and firewalls decide exactly what can talk to what.

Scope and boundaries

PropertyRule
RegionA VNet exists in exactly one region — it cannot span regions
SubscriptionBelongs to one subscription
Availability ZonesAutomatically spans all zones within its region
Cross-regionConnect separate VNets using peering

Private address ranges (RFC 1918)

VNets use private IP space. These three ranges are reserved for private networks worldwide:

RangeCIDRAvailable addresses
10.x.x.x10.0.0.0/8~16.7 million
172.16–31.x.x172.16.0.0/12~1 million
192.168.x.x192.168.0.0/16~65,000
⚠️

Plan your address space before you build. VNets you intend to peer must not have overlapping ranges — and fixing an overlap later means rebuilding, not editing. Reserve a distinct block per environment and region from day one.

Public vs private IPs

Private IPPublic IP
Reachable fromInside the VNet (and peered/VPN networks)The internet
Assigned toEvery VM automaticallyOnly if you add one
CostFreeCharged per IP
SKUsBasic (retiring) and Standard
📌

Static allocation

The address never changes. Required for DNS records, firewall allow-lists and domain controllers.

🎲

Dynamic allocation

May change when the VM is deallocated and restarted. Fine for most workloads.

💡

Best practice: keep databases and backend VMs on private IPs only. Expose just the front door to the internet — ideally through a load balancer or Application Gateway rather than a raw public IP on the VM.

Name resolution

By default, Azure provides DNS for every VNet automatically — VMs can resolve each other by hostname with no configuration. You can override this with custom DNS servers (common when integrating with on-premises Active Directory), or use Azure Private DNS zones for your own private domain names.

Creating a VNet with a subnet:

az network vnet create \
  --resource-group rg-lab-prod-cin \
  --name vnet-prod-cin \
  --address-prefix 10.20.0.0/16 \
  --subnet-name snet-web \
  --subnet-prefix 10.20.1.0/24
ℹ️

VNets themselves are free. You pay for what runs inside them and for certain gateways — VPN Gateway, NAT Gateway and ExpressRoute all carry hourly charges, so remember to delete lab gateways when you're done.

Module 4 — Networking

Subnets & IP Addressing in Azure

A subnet divides your VNet's address space into smaller segments. Subnets are how you separate tiers — web, application, database — so each can have its own security rules and routing.

Reading CIDR notation

The number after the slash says how many bits are fixed as the network portion. A bigger number means a smaller network:

CIDRTotal addressesAzure usableTypical use
/1665,53665,531A whole VNet
/24256251A standard subnet
/266459A small tier
/273227Gateway subnet minimum
/2983Smallest allowed subnet
⚠️

Azure reserves five addresses in every subnet, not the usual two. In 10.0.1.0/24: .0 network, .1 gateway, .2 and .3 Azure DNS, .255 broadcast. So a /24 gives 251 usable, not 254 — a very common exam question.

A typical three-tier layout

SubnetRangeContainsInternet access
snet-web10.20.1.0/24Front-end servers, load balancerInbound 80/443
snet-app10.20.2.0/24Application servers, APIsNone inbound
snet-data10.20.3.0/24DatabasesNone at all
GatewaySubnet10.20.255.0/27VPN / ExpressRoute gatewayManaged by Azure
ℹ️

Some subnets must use exact reserved names: GatewaySubnet for VPN/ExpressRoute gateways, AzureFirewallSubnet for Azure Firewall, AzureBastionSubnet for Bastion. Get the spelling wrong and the service simply won't deploy.

Sizing subnets

📏

Don't go too small

Resizing a subnet that already has resources in it is painful. Leave headroom for growth.

🧮

Account for scale sets

A VMSS that can reach 50 instances needs 50 free IPs — plus Azure's five reserved.

🔌

Private endpoints eat IPs

Every private endpoint consumes an address from the subnet it lands in.

📊

/24 is a sane default

251 usable addresses covers most tiers without wasting space.

Service endpoints vs private endpoints

Both let VNet resources reach PaaS services like Storage or SQL more securely, but they work differently:

Service endpointPrivate endpoint
How it worksTraffic stays on Azure's backbone; service still has a public IPService gets a private IP inside your subnet
Uses a subnet IPNoYes
Reachable from on-premisesNoYes, over VPN/ExpressRoute
CostFreeCharged hourly + data
💡

Private endpoints are the more secure and more flexible option, and are where Microsoft is steering new designs. Use service endpoints when cost matters more and on-premises access isn't needed.

Routing basics

Azure creates system routes automatically so everything inside a VNet can reach everything else. You override them with a User Defined Route (UDR) in a route table — most often to force traffic through a firewall or network virtual appliance before it leaves.

az network vnet subnet create \
  --resource-group rg-lab-prod-cin \
  --vnet-name vnet-prod-cin \
  --name snet-data \
  --address-prefix 10.20.3.0/24
Module 4 — Networking

Network Security Groups (NSG)

An NSG is a distributed firewall that filters traffic to and from Azure resources. It holds a prioritized list of allow/deny rules, evaluated in order until one matches.

The rules that matter

🔢

Priority 100–4096

Lower numbers evaluate first. Leave gaps (100, 200, 300) so you can insert rules later.

🛑

First match wins

Evaluation stops at the first matching rule. Everything below it is never considered.

↔️

Stateful

Allow traffic in and the reply is automatically allowed out. No return rule needed.

📍

Two attach points

Associate to a subnet, a NIC, or both. Subnet rules apply first for inbound traffic.

Try it: watch rule evaluation

This NSG protects a web server. Pick an incoming packet and watch which rule catches it — notice how everything below the matching rule is never even reached.

What defines a rule

FieldExample
Priority100 — lower is evaluated first
Source / destinationIP, CIDR, service tag or ASG
ProtocolTCP, UDP, ICMP or Any
Port range443, 1000-2000, or *
DirectionInbound or Outbound
ActionAllow or Deny

Default rules you can't delete

PriorityRuleEffect
65000AllowVnetInBoundAnything inside the VNet can talk to anything else
65001AllowAzureLoadBalancerInBoundHealth probes can reach your resources
65500DenyAllInBoundEverything else inbound is blocked
ℹ️

Because AllowVnetInBound exists at 65000, resources in different subnets of the same VNet can reach each other by default. If you want tier isolation, you must add explicit deny rules at a lower priority number.

Service tags

Rather than maintaining IP lists, use service tags — Microsoft-managed labels that stay current automatically: Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AzureCloud.

⚠️

Two NSGs in the path (one on the subnet, one on the NIC) means traffic must be allowed by both. This is the most common cause of "my rule looks right but it's still blocked" — always check both layers.

💡

When connectivity breaks, use NSG diagnostics or IP flow verify in Network Watcher. It tells you exactly which rule allowed or denied the packet, instead of guessing — covered in the last lesson of this module.

Module 4 — Networking

Application Security Groups & VNet Peering

Two features that make networks easier to manage as they grow: ASGs let you write rules about roles instead of IP addresses, and peering connects VNets together privately.

The problem ASGs solve

Without ASGs, NSG rules reference IP addresses. Add a web server and you must edit every rule that mentions the web tier. With ASGs you group NICs by role and write rules against the group name — new servers just join the group.

Without ASGWith ASG
Rule source10.20.1.4, 10.20.1.5, 10.20.1.6asg-web
Adding a serverEdit every affected ruleAdd the NIC to the ASG
ReadabilityWhich IP was the database?Self-documenting
🌐
asg-web Accepts 443 from internet
⚙️
asg-app Accepts 8080 from asg-web
🗄️
asg-db Accepts 1433 from asg-app
ℹ️

ASGs are attached to network interfaces, not subnets — so two VMs in the same subnet can belong to different ASGs and get completely different rules. All ASGs used together in one rule must be in the same VNet.

VNet peering

Peering connects two VNets so resources talk over Microsoft's backbone using private IPs — no VPN gateway, no public internet, low latency.

Low latency

Traffic stays on the Azure backbone at near-native speed.

🌍

Global peering

Works across regions and even across subscriptions or tenants.

🔧

No gateway needed

Nothing to deploy or maintain — it's a configuration, not a resource.

💵

Charged on data

You pay per GB in and out. Global peering costs more than same-region.

Three rules that trip people up

🚫

No overlapping ranges

Peering fails outright if address spaces overlap. Plan IP space in advance.

↔️

Peering isn't automatic both ways

A link must be created from each VNet. One-sided peering shows "Initiated" and doesn't work.

🔗

Not transitive

If A↔B and B↔C, A still cannot reach C. You need A↔C, or routing through an appliance.

⚠️

Non-transitivity is the single most-tested peering fact. In a hub-and-spoke design, spokes cannot talk to each other through the hub by default — that requires user-defined routes pointing at a firewall or NVA in the hub.

Hub-and-spoke

The standard enterprise pattern: a central hub VNet holds shared services (firewall, VPN gateway, DNS, Bastion), and each workload lives in its own spoke peered to the hub. It centralizes security and cuts costs, since one gateway serves every spoke.

Peering settingWhat it does
Allow forwarded trafficAccept traffic that didn't originate in the peer VNet — needed for hub routing
Allow gateway transitLet spokes use the hub's VPN/ExpressRoute gateway
Use remote gatewaysSet on the spoke to consume the hub's gateway
az network vnet peering create \
  --resource-group rg-lab-prod-cin \
  --name hub-to-spoke1 \
  --vnet-name vnet-hub \
  --remote-vnet vnet-spoke1 \
  --allow-vnet-access --allow-forwarded-traffic

Connecting to on-premises

OptionRuns overBest for
Point-to-Site VPNInternetIndividual remote users
Site-to-Site VPNEncrypted internet tunnelConnecting a whole office
ExpressRoutePrivate dedicated circuitEnterprise workloads needing guaranteed bandwidth
Module 4 — Networking

Azure Network Watcher & Network Troubleshooting

Network Watcher is the diagnostic toolbox for Azure networking. Rather than guessing why traffic is blocked, these tools tell you exactly which rule or route is responsible.

The diagnostic tools

🔍

IP flow verify

Answers "can this packet get through?" and names the exact NSG rule that allowed or denied it.

🗺️

Next hop

Shows where a packet goes next — internet, VNet, virtual appliance — revealing bad routes.

🔗

Connection troubleshoot

Tests real connectivity between two endpoints and reports latency and hop-by-hop results.

📊

NSG flow logs

Records every allowed and denied flow to storage for later analysis.

📦

Packet capture

Captures actual traffic on a VM for deep inspection in Wireshark.

📈

Connection monitor

Ongoing reachability and latency monitoring with alerting.

ℹ️

Network Watcher is enabled automatically, per region, when you create a VNet. It's a regional service — check you're looking at the right region if the tools appear missing.

A troubleshooting method that works

StepCheckTool
1Is the VM actually running (not deallocated)?Portal overview
2Is traffic allowed by NSG rules?IP flow verify
3Are BOTH the subnet and NIC NSGs allowing it?Effective security rules
4Is the packet routed where you expect?Next hop
5Is the service listening inside the OS?Serial console / netstat
6Is the guest OS firewall blocking it?Serial console
💡

Effective security rules is the most underused view in Azure. It merges every NSG applying to a NIC — subnet plus NIC, custom plus default — into one list showing what's genuinely in force. Start there instead of reading NSGs separately.

Common failures and their causes

SymptomUsual cause
Can't RDP/SSH from the internetNSG missing an allow rule, or VM has no public IP
Rule looks correct but traffic still blockedA second NSG on the other layer is denying it
VMs in peered VNets can't communicatePeering only created from one side, or overlapping ranges
Spoke can't reach another spokePeering isn't transitive — needs a UDR via the hub firewall
Load balancer backend shows unhealthyHealth probe port blocked, or the app isn't listening
Can reach by IP but not by nameDNS misconfiguration or a missing private DNS zone link
Outbound internet stopped workingA UDR is forcing traffic to an appliance that's down

Reading NSG flow logs

Flow logs write every connection to storage as JSON. Paired with Traffic Analytics, they answer questions raw logs can't: which hosts talk most, what's being denied repeatedly, and whether anything is scanning your subnets.

# Is this packet allowed, and by which rule?
az network watcher test-ip-flow \
  --vm web-vm-01 \
  --direction Inbound \
  --protocol TCP \
  --local 10.20.1.4:443 \
  --remote 198.51.100.7:60000
⚠️

Remember NSGs are stateful. If inbound is allowed, the response is automatically permitted — so a blocked reply almost never means a missing outbound rule. Look at routing or the guest OS firewall instead.

💡

Enable NSG flow logs on production subnets before you have an incident. They're inexpensive, and without them you're reconstructing an outage from memory rather than evidence.

Module 4 — Networking

Module 4 Exam

Twelve questions on virtual networks, subnets, IP addressing, NSGs, ASGs, peering and troubleshooting. Aim for 70% or better before moving on.

Module 5 — Load Balancing & Content Delivery

Azure Load Balancer

Azure Load Balancer distributes incoming traffic across a pool of backend servers. It operates at Layer 4 — it sees IP addresses and ports, not URLs or content — which makes it extremely fast and protocol-agnostic.

Try it: watch traffic get distributed

Send requests through the load balancer and watch which backend server receives each one. Then take a server down and see how health probes reroute traffic away from it.

⚖️ LB
💡 Press "Send request" to route traffic through the load balancer.

The four components

🌐

Frontend IP

The address clients connect to — public for internet traffic, private for internal.

🖥️

Backend pool

The VMs or scale set instances that actually serve requests.

❤️

Health probe

Periodically tests each backend. Failing instances are removed from rotation.

📏

Load balancing rule

Maps a frontend port to a backend port and ties the pieces together.

Public vs internal

Public Load BalancerInternal (Private) Load Balancer
Frontend IPPublicPrivate, inside the VNet
Reachable fromThe internetOnly the VNet and connected networks
Typical usePublic web tierBalancing an internal app or database tier

Basic vs Standard SKU

FeatureBasicStandard
Backend instancesUp to 300Up to 1,000
Availability ZonesNot supportedZone redundant
SLANone99.99%
Secure by defaultOpen unless an NSG blocksClosed unless an NSG allows
StatusBeing retiredUse this for anything new
⚠️

Standard Load Balancer is closed by default — traffic is denied unless an NSG explicitly allows it. Migrating from Basic and forgetting this is a classic "everything broke after the upgrade" moment.

Health probes

Probe typeConsiders healthy when…Best for
TCPThe TCP handshake completes on the probe portNon-HTTP services
HTTPThe path returns HTTP 200Web apps — can test real app health
HTTPSThe path returns HTTP 200 over TLSSecure web apps (Standard SKU only)
💡

Point HTTP probes at a dedicated endpoint like /health that checks the app's real dependencies (database reachable, cache up). Probing / only proves the web server is running — not that your application actually works.

Distribution modes

ModeHashes onEffect
5-tuple (default)Source IP, source port, dest IP, dest port, protocolEven spread; a client may hit different servers
Source IP affinity (2-tuple)Source and destination IPA client sticks to one server — "session persistence"
3-tupleSource IP, dest IP, protocolMiddle ground
ℹ️

Needing source IP affinity usually signals that your app stores session state in server memory. The more scalable fix is externalizing session state to Redis or a database, so any server can serve any request.

az network lb create \
  --resource-group rg-lab-prod-cin \
  --name lb-web-prod \
  --sku Standard \
  --frontend-ip-name fe-public \
  --backend-pool-name bp-web
⚠️

If every backend shows unhealthy, check three things in order: the probe port is open in the NSG, the application is actually listening on that port, and the probe path returns exactly HTTP 200 (a 301 redirect counts as a failure).

Module 5 — Load Balancing & Content Delivery

Azure Application Gateway

Application Gateway is a Layer 7 load balancer. Unlike the Layer 4 Load Balancer, it can read the actual HTTP request — the URL path, the hostname, the headers — and route based on what it finds.

Try it: path-based routing

Click a URL and watch which backend pool the gateway selects by inspecting the path.

💡 Pick a URL above to see how the gateway routes it.

What Layer 7 makes possible

🛣️

Path-based routing

Send /api/* to one pool and /images/* to another.

🏷️

Multi-site hosting

Host many domains behind one gateway, routed by hostname.

🔐

SSL termination

Decrypt TLS at the gateway so backends don't spend CPU on it.

🍪

Cookie affinity

Keep a user's session pinned to the same backend server.

🛡️

Web Application Firewall

Block SQL injection, XSS and the rest of the OWASP top 10.

↪️

Redirects & rewrites

Force HTTPS, or rewrite URLs and headers in flight.

How a request flows through

🌐
Frontend IP Client connects
👂
Listener Port, protocol, hostname
📏
Routing rule Inspects the path
🖥️
Backend pool Serves the response

Web Application Firewall modes

ModeBehaviourUse when
DetectionLogs threats but allows them throughInitial tuning, to find false positives safely
PreventionBlocks matching requests outrightProduction, once tuned
💡

Always start WAF in Detection mode and review the logs for a week. Switching straight to Prevention on a real app frequently blocks legitimate traffic — file uploads and rich text editors are common false positives.

Choosing between the load balancers

Load BalancerApplication Gateway
Layer4 (TCP/UDP)7 (HTTP/HTTPS)
Routing onIP and portURL path, hostname, headers
ScopeRegionalRegional
SSL terminationNoYes
WAFNoYes
ProtocolsAny TCP/UDPHTTP/HTTPS only
Choose forDatabases, non-HTTP services, raw speedWeb apps needing content-aware routing
ℹ️

Application Gateway needs its own dedicated subnet — nothing else can live in it. Size it at least /24 for the v2 SKU, which needs room to scale out its instances.

⚠️

Application Gateway is regional. To route users between regions you need Traffic Manager or Front Door in front of it — covered in the next lessons.

Module 5 — Load Balancing & Content Delivery

Azure DNS

Azure DNS hosts your domain's DNS records on Microsoft's global network of name servers. It doesn't sell you domains — you register elsewhere and delegate the name servers to Azure.

How a DNS lookup works

💻
Client Needs an IP
🔄
Resolver ISP or public DNS
🌍
Root & TLD Points to your NS
📇
Azure DNS Returns the record

Record types you'll actually use

TypeMapsExample
AName → IPv4 addresswww20.44.12.8
AAAAName → IPv6 addresswww2603:1010::4
CNAMEName → another nameshopapp.azurewebsites.net
MXDomain → mail server@mail.example.com
TXTArbitrary textSPF, DKIM, domain verification
NSZone → authoritative name serversCreated automatically
SRVService → host and portSIP, Microsoft Teams
PTRIP → name (reverse lookup)Mail server reputation
⚠️

You cannot create a CNAME at the zone apex (example.com itself) — DNS standards forbid it. Azure's answer is the alias record, which points the apex directly at an Azure resource such as a public IP, Traffic Manager profile or Front Door endpoint.

Alias records

🔗

Apex support

Point example.com straight at an Azure resource — no CNAME needed.

🔄

Auto-updating

If the target resource's IP changes, the record follows automatically.

🧹

Dangling-record protection

Delete the resource and the record resolves to nothing rather than to someone else's takeover.

Public vs private zones

Public DNS zonePrivate DNS zone
Resolvable fromThe whole internetOnly linked VNets
Typical useYour public website and mailInternal names, private endpoints
Auto-registrationNoOptional — VMs register themselves
ℹ️

Private DNS zones are essential for private endpoints. Without the right zone linked to your VNet, a name like mystorage.blob.core.windows.net still resolves to its public IP, and traffic bypasses your private link entirely.

TTL — time to live

TTL tells resolvers how long to cache a record. Long TTLs reduce lookups and cost; short TTLs let changes propagate fast.

💡

Before a planned migration, lower the TTL to 300 seconds a day or two in advance. Then the cutover propagates in minutes. Lowering it at the same time as the change doesn't help — resolvers are still holding the old, long-TTL answer.

az network dns record-set a add-record \
  --resource-group rg-lab-prod-cin \
  --zone-name veplearn.example \
  --record-set-name www \
  --ipv4-address 20.44.12.8
Module 5 — Load Balancing & Content Delivery

Azure Traffic Manager

Traffic Manager is a DNS-based global load balancer. It doesn't carry your traffic — it answers DNS queries with the IP of whichever endpoint its routing method selects, and the client then connects directly.

ℹ️

This DNS-level design has one big consequence: because clients cache DNS answers, failover isn't instant. It takes as long as the record's TTL to fully take effect — which is why TTLs on Traffic Manager profiles are usually set very low (30–60 seconds).

The six routing methods

MethodSends users toUse case
PriorityThe highest-priority healthy endpointActive/passive failover to a DR region
WeightedEndpoints in proportion to assigned weightsBlue/green and canary releases
PerformanceThe region with lowest measured latencyGlobal apps optimizing speed
GeographicThe endpoint mapped to the user's countryData sovereignty, localized content
MultivalueSeveral healthy IPs at onceClient-side retry across endpoints
SubnetAn endpoint mapped to the user's IP rangeDifferent experience for office vs public users

Priority vs Performance vs Geographic

1️⃣

Priority

Everyone goes to endpoint 1. Only if it fails does traffic move to endpoint 2. Classic DR.

Performance

Each user reaches the fastest region for them — based on real latency tables, not distance.

🌍

Geographic

Users are routed by the country their DNS query came from — a compliance tool, not a speed tool.

⚠️

Don't confuse Performance and Geographic. Performance optimizes speed and may send an Indian user to Singapore if it's faster. Geographic guarantees an Indian user goes to the India endpoint even if it's slower — which is what data-residency rules actually require.

Endpoint types

TypePoints at
Azure endpointAn Azure resource — App Service, public IP, Application Gateway
External endpointAny public IP or FQDN, including on-premises or another cloud
Nested endpointAnother Traffic Manager profile, for combining routing methods
💡

Nested profiles are how you combine methods. A common pattern: a Geographic parent sends EU users to an EU child profile, which then uses Performance to pick the fastest EU region. Compliance and speed together.

Traffic Manager vs Front Door

Traffic ManagerFront Door
Works atDNS layerHTTP layer (reverse proxy)
Carries trafficNo — client connects directlyYes — traffic flows through it
ProtocolsAnyHTTP/HTTPS only
Failover speedLimited by DNS TTLNear-instant
Caching / WAFNoYes
ℹ️

For modern web applications, Front Door is usually the better choice. Traffic Manager remains the right tool when you need to route non-HTTP protocols globally — or to direct traffic to endpoints outside Azure entirely.

Module 5 — Load Balancing & Content Delivery

Azure Front Door & CDN

Front Door is Microsoft's global entry point for web applications: a reverse proxy running at edge locations worldwide that combines global load balancing, caching, SSL offload and a web application firewall.

Why the edge matters

A user in Chennai requesting content from a server in Virginia waits for the round trip. An edge node in Chennai serving a cached copy answers in milliseconds. Front Door also terminates TLS at the edge, so the expensive handshake happens close to the user.

👤
User Chennai
📡
Edge POP Cached? Serve instantly
🌐
Microsoft backbone Fast private network
🖥️
Origin Only on cache miss

What Front Door provides

🌍

Global load balancing

Routes each user to the nearest healthy backend, across regions.

Edge caching

Static content served from the POP nearest the user.

🛡️

WAF & DDoS

Attacks are absorbed at the edge, far from your origin.

🔐

Free managed TLS

Certificates issued and auto-renewed by Microsoft.

🔀

Path routing & rewrites

Layer 7 rules just like Application Gateway, but global.

⚙️

Rules engine

Custom header, redirect and caching logic evaluated at the edge.

Caching behaviour

ConceptMeaning
Cache hitThe edge had the content and served it directly — fastest path
Cache missThe edge fetched from origin, then stored it for next time
TTLHow long the edge keeps content, driven by Cache-Control headers
PurgeManually evicting content after a deployment
Query string handlingWhether ?v=2 counts as a different cached object
⚠️

Never cache authenticated or personalized responses at the edge — you risk serving one user's private page to another. Set Cache-Control: private, no-store on anything user-specific.

💡

Rather than purging after every deploy, use cache-busting filenames like app.4f2a91.js. A new build produces a new filename, so the edge fetches it immediately while old files expire naturally.

Front Door vs CDN

Azure CDNFront Door
Primary purposeCaching static contentGlobal app delivery and acceleration
Load balancingNoYes, with health probes
WAFLimitedFull
Dynamic contentNot acceleratedAccelerated over the backbone
ℹ️

Microsoft has consolidated these into Azure Front Door Standard/Premium, which merges classic CDN and Front Door capabilities into one product. Premium adds the full WAF ruleset, private-link origins and bot protection.

Choosing the right service — the summary

NeedService
Balance TCP/UDP inside one regionLoad Balancer
URL-based routing + WAF in one regionApplication Gateway
Route any protocol globally via DNSTraffic Manager
Global HTTP delivery with caching and WAFFront Door
💡

The two questions that resolve almost every exam scenario: regional or global? and HTTP or any protocol? Regional + any protocol → Load Balancer. Regional + HTTP → Application Gateway. Global + any protocol → Traffic Manager. Global + HTTP → Front Door.

Module 5 — Load Balancing & Content Delivery

Module 5 Exam

Twelve questions on Load Balancer, Application Gateway, DNS, Traffic Manager and Front Door. Aim for 70% or better before moving on.