Episode 3 — VM Disks, Security, and Day-2 Administration

In Episode 2 — Virtual Machines: Anatomy and Provisioning, you deployed a VM and decoded everything it dragged along with it. Now we go one layer down — the disks your VM lives on — and one step forward: keeping that VM secure and healthy after day one.

Learning objectives

• Explain the roles of the OS disk, temp disk, and data disks, and why the temp disk must never hold real data.
• Choose the right managed disk type for a workload using cost, latency, and IOPS criteria.
• Configure everyday disk operations: resize, snapshots, and host caching.
• Choose between SSE (PMK/CMK), Azure Disk Encryption, and encryption at host for a given requirement.
• Administer VMs securely with Azure Bastion and just-in-time access, and troubleshoot with redeploy and boot diagnostics.

Why it matters

Compute is stateless until it isn't: the moment your VM stores anything, disks become the real asset — and the main way to waste money or lose data. On the exam, disk types, encryption options, and secure-access patterns are classic AZ-104 question territory because the options look interchangeable until you know the one criterion that separates them. In the real world, the stakes are higher: a database on the wrong disk tier crawls, data written to a temp disk vanishes on the next deallocation, and a VM with RDP open to the internet gets found by scanners within minutes of creation.

Three disks, three roles

Every VM sees up to three kinds of disks, and confusing them is the classic day-one incident.

The OS disk holds the operating system, registered as C: on Windows or /dev/sda on Linux. It is a managed disk: Azure stores it as a replicated object in its storage backend, so it survives host failures and deallocation. Maximum size is generous (up to 4 TiB), but keep it lean — applications and data belong elsewhere.

The temp disk is different in kind, not just in size. It is ephemeral local storage on the physical host, surfaced on Windows as D: by default and typically mounted at /dev/sdb or /mnt on Linux. Its contents are lost on deallocate, redeploy, or host failure — that's by design. Use it only for page files, swap, caches, and scratch data you can recreate. And note a trap: some newer VM sizes ship with no temp disk at all (the size name often signals it — Episode 2's decoding skills apply), so never script against D: existing.

Data disks are additional managed disks you attach for application data — databases, file shares, logs. They have their own type, size, and caching setting per disk, which is exactly where the next section comes in.

Choosing a managed disk type

Azure offers five managed disk types. The differences that matter are latency, IOPS/throughput, how performance scales, and price — plus one hard rule: Premium SSD v2 and Ultra Disk cannot be OS disks; they are data disks only.

Two design consequences worth internalizing. First, the single-VM SLA of 99.9% requires Premium SSD or better on all disks — a Standard SSD OS disk silently forfeits it. Second, with classic Premium SSD, performance scales with size, so teams often over-provision capacity just to buy IOPS; Premium SSD v2 decouples the two, letting you pay for exactly the capacity and performance you need. Exact IOPS and throughput caps shift over time — think "thousands for Premium, far more for v2 and Ultra" and check current limits before committing an architecture.

Exercise 3.1 — Match the disk to the workload

For each workload, pick the most appropriate disk type:

Solution:

• a — Standard SSD. Dev/test doesn't need the single-VM SLA or premium performance; Standard SSD keeps latency consistent at low cost. Standard HDD would work but makes even test cycles sluggish.
• b — Premium SSD. Production database, latency-sensitive, and it may need to sit under an SLA. Premium SSD v2 is also defensible if supported in your region and configuration — but the safe default answer is Premium SSD.
• c — Standard HDD. Cold, sequential, rarely read: the one scenario where spinning disks still win on price.
• d — Ultra Disk. "Sub-millisecond" is the trigger word: only Ultra promises it. Remember it can't be the OS disk — the OS disk stays Premium SSD.
• e — Premium SSD v2. High IOPS on small capacity is exactly the mismatch classic Premium SSD punishes (performance tied to size). v2 lets you dial up IOPS independently.

Everyday disk operations

Resizing is a one-way street: you can expand a managed disk, never shrink it. Expanding a data disk is a quick az disk update; depending on disk type and size, you may be able to do it without stopping the VM — downtime-free expansion keeps gaining scenarios, so check the current constraints for your disk type. After expanding, remember to grow the partition and filesystem inside the guest OS — Azure only makes the raw disk bigger.

az disk update \
  --resource-group myRG \
  --name myDataDisk \
  --size-gb 512

Snapshots are point-in-time, read-only copies of a disk — your raw material for backups, disk duplication, and "before I touch prod" insurance. Prefer incremental snapshots: after the first one, you're billed only for the changed data, and they're the foundation for efficient cross-region copies.

az snapshot create \
  --resource-group myRG \
  --name myDataDisk-snap-001 \
  --source myDataDisk \
  --incremental true

Host caching puts a read/write cache on the VM's host between the guest and the storage backend. The setting is per disk, and the guidance is stable:

Two cautions: ReadWrite on a data disk risks data loss unless the application explicitly manages flushes (databases generally do not want this), and host caching isn't available everywhere — Ultra Disk and Premium SSD v2 don't support it, nor do very large disks (above ~4 TiB). Changing the cache setting on an attached disk can briefly interrupt the VM, so plan it.

Encryption: three options, three layers

Azure gives you three disk-encryption mechanisms, and exam questions love to blur them. The distinction is where the encryption happens.

SSE (Server-Side Encryption) is always on for every managed disk — you cannot turn it off, and with PMK you never think about it. Switching to CMK changes who holds the keys, not where encryption happens: your key lives in Azure Key Vault, referenced through a disk encryption set, and revoking it renders the disks unreadable.

ADE runs inside the VM using the OS's native volume encryption. It satisfies auditors who require guest-level encryption, but it adds an in-guest dependency and cannot be combined with encryption at host — pick one.

Encryption at host encrypts data on the physical host itself, so everything — including the temp disk and host caches, which SSE alone never touches — flows encrypted end to end. It needs a one-time feature registration on the subscription and a supported VM size, but for new designs it's usually the strongest low-friction choice.

Memory hook: "Rest, Guest, Best." SSE encrypts at rest in the storage backend; ADE encrypts inside the guest; encryption at host is usually the best modern pick because it closes the temp-disk-and-cache gap.

Exercise 3.2 — Pick the encryption option

Choose the right mechanism for each requirement:

1. An auditor requires that your organization can rotate and revoke the encryption keys protecting VM disks.
2. Security policy states that temp disks and disk caches must be encrypted, with no agents inside the guest OS.
3. A regulation explicitly requires BitLocker-based volume encryption inside Windows VMs, with keys escrowed in Key Vault.

Solution:

1. SSE with CMK. The requirement is about key control, not encryption location. A disk encryption set pointing at your Key Vault key gives rotation and revocation; no guest changes needed.
2. Encryption at host. It's the only option that covers temp disks and caches, and it works at the host layer — nothing installed in the guest. SSE alone fails the temp-disk requirement; ADE fails the no-agent requirement.
3. Azure Disk Encryption. The regulation names the in-guest mechanism (BitLocker), which is exactly what ADE orchestrates. Note that choosing ADE here means you cannot also enable encryption at host on the same VM.

Secure access: no public RDP or SSH, ever

A public IP with port 3389 or 22 open is an invitation: internet scanners find fresh VMs in minutes and start hammering credentials. The rule is simple — management ports never face the internet. Azure gives you two complementary tools.

Azure Bastion is a managed jump host deployed into a dedicated AzureBastionSubnet in your virtual network. You connect to the Azure portal over HTTPS (443), and Bastion opens the RDP/SSH session to the VM over its private IP. The VM needs no public IP at all, and nothing but Bastion ever speaks RDP/SSH to it. Higher Bastion SKUs add conveniences such as native-client connections — check current SKU features when sizing.

Just-in-time (JIT) VM access, part of Microsoft Defender for Cloud (it requires the Defender for Servers plan), takes the opposite approach for cases where direct access must exist: ports stay closed by default in the NSG, and an authorized admin requests a time-boxed opening — for a specific source IP, for a few hours — after which the rule closes automatically. Bastion removes the exposure; JIT minimizes its window. Many environments use Bastion for humans and keep JIT for the exceptions.

Day-2 administration

Once a VM is running, four routines cover most operational life.

Resize the VM when the workload outgrows (or under-uses) its size. Resizing to a size available on the current hardware cluster is a restart; if the target size isn't available there, deallocate first — a deallocated VM can restart on any cluster in the region, unlocking the full size catalog.

az vm resize \
  --resource-group myRG \
  --name myVM \
  --size Standard_D8s_v5

Redeploy is the underrated first-line fix when a VM is unreachable and nothing in your configuration explains it: Azure moves the VM to a new physical host and boots it again. Configuration and managed disks are preserved, but the temp disk is wiped and dynamic IP addresses can change — one more reason the temp disk holds nothing precious.

az vm redeploy --resource-group myRG --name myVM

Boot diagnostics captures a console screenshot and serial log so you can see why a VM won't boot — kernel panic, chkdsk loop, broken fstab — without any working network path into the guest. It's cheap insurance; enable it everywhere.

az vm boot-diagnostics enable --resource-group myRG --name myVM
az vm boot-diagnostics get-boot-log --resource-group myRG --name myVM

Finally, Azure Update Manager centralizes OS patching across your Azure (and Arc-connected hybrid) machines: it assesses missing updates, lets you define maintenance schedules so reboots happen in agreed windows, and reports compliance across the estate. For any fleet beyond a handful of VMs, hand-patching is not a strategy — put Update Manager between you and patch Tuesday.

Key takeaways

• The temp disk is ephemeral: lost on deallocate or redeploy, D: on Windows, absent on some newer sizes — scratch data only.
• Five managed disk types; Premium SSD v2 and Ultra are data disks only, and the single-VM 99.9% SLA requires Premium SSD or better.
• Disks expand but never shrink; grow the guest filesystem after expanding; prefer incremental snapshots.
• Host caching: ReadWrite for OS, ReadOnly for read-heavy data, None for write-heavy/log disks.
• Encryption: SSE at rest (always on), ADE in the guest, encryption at host end-to-end — only the last covers temp disks and caches. Rest, Guest, Best.
• Never expose RDP/SSH publicly: Azure Bastion for routine access, JIT to time-box the exceptions.
• Day-2 toolkit: resize (deallocate to unlock more sizes), redeploy to a new host, boot diagnostics for boot failures, Azure Update Manager for patching.

Quick recall

Q: What happens to temp disk data when a VM is deallocated or redeployed? A: It's lost. The temp disk is ephemeral local storage on the host — use it only for data you can recreate.

Q: Which managed disk types cannot be used as OS disks? A: Premium SSD v2 and Ultra Disk — they're data disks only.

Q: What's the minimum disk tier for the single-VM 99.9% SLA? A: Premium SSD (or better) on all disks attached to the VM.

Q: Which encryption option covers the temp disk and host caches? A: Encryption at host — SSE only protects managed disks at rest, and ADE works inside the guest.

Q: A VM is unreachable and its config looks fine. Cheap first move? A: Redeploy it — Azure moves it to a new host. Expect the temp disk to be wiped and dynamic IPs to possibly change.

Q: Why choose Azure Bastion over a public IP locked down by an NSG? A: Bastion removes public RDP/SSH exposure entirely: you connect over HTTPS 443 and Bastion reaches the VM on its private IP.

Coming up

One well-secured VM is still one VM — a single point of failure with a 99.9% ceiling. In Episode 4 — High Availability and Scaling: Sets, Zones, and Scale Sets, we spread workloads across fault domains, update domains, and availability zones, and let VM Scale Sets grow and shrink your fleet automatically. Bring your SLA math.