Cloud / Azure Disk Storage Interview questions

Azure Disk Storage provides block-level storage volumes for Azure virtual machines. A disk behaves like the physical drive in an on-premises server, except the platform handles placement, replication and scaling for you.

Disks are exposed to the VM as raw block devices. They hold the operating system, application data, logs and databases, and they stay durable even if the VM is stopped or moved to another host.

Under the hood each managed disk is stored with multiple synchronous copies (three within one datacenter for LRS, or across zones for ZRS).

A managed disk is an Azure resource (Microsoft.Compute/disks) where you pick only the disk type and size. Azure creates and manages the underlying storage, so there is no storage account for you to plan, throttle or secure.

• Supports RBAC, tags and Azure Policy on the disk itself
• Works with availability zones and availability sets
• Integrates with snapshots, images, Azure Backup and encryption sets

Unmanaged disks (VHDs in your own storage account) were retired on September 30, 2025, so new designs should always use managed disks.

Azure offers five managed disk types, ordered roughly from highest to lowest performance:

Only Premium SSD, Standard SSD and Standard HDD can be used as OS disks.

Pick the type from measured IOPS and latency needs, not by defaulting to the fastest one. Ultra Disk and Premium SSD v2 are also zonal, so the VM must sit in the same zone.

The OS disk holds the boot volume of a VM. It is created from a marketplace image, a custom image or a snapshot and shows up as C: on Windows or the root device on Linux.

It can be Premium SSD, Standard SSD or Standard HDD. Ultra Disk and Premium SSD v2 cannot be used as OS disks. The default host caching setting for an OS disk is ReadWrite.

If the VM is stateless you can place the OS disk on local storage instead, using an ephemeral OS disk.

A data disk is an additional managed disk attached to a VM to store application data, database files or logs. How many you can attach depends on the VM size, and each disk can be up to 32 TiB (64 TiB for Ultra and Premium SSD v2).

A new data disk arrives as an unformatted device. Inside the guest you must initialize it, create a partition, format it and mount it. The default host caching for data disks is None.

az vm disk attach --resource-group rg-app --vm-name vm01 --name data01 --new --size-gb 512 --sku Premium_LRS

The temporary disk is local storage on the physical host. It appears as D: on Windows and /dev/sdb (mounted at /mnt) on Linux. Not every VM size has one.

Its contents are not persistent. Data can be lost when the VM is redeployed, resized, or moved to another host after a failure. Because it is local it is fast, so it suits page files and scratch data.

Never keep your only copy of important data there, and note that Azure Backup does not cover it.

Ultra Disk is the highest-performance managed disk, built for latency-sensitive tier-0 workloads such as SAP HANA and large transactional databases. It scales to 64 TiB, 400,000 IOPS and 10,000 MB/s per disk with sub-millisecond latency.

Capacity, IOPS and throughput are set independently, and you can change IOPS and throughput on a running disk without detaching it.

• Data disk only, never an OS disk
• Host caching is not supported
• Available only in selected regions and zones (create it with a zone)

Premium SSD v2 lets you provision capacity, IOPS and throughput separately instead of buying a fixed size tier. Capacity can be set in 1 GiB steps up to 64 TiB, with up to 80,000 IOPS and 1,200 MB/s per disk.

Every disk includes a free baseline of 3,000 IOPS and 125 MB/s. You pay extra only for what you add beyond that.

Limitations: data disk only, no host caching, and the disk is zonal, so it must be created in the same zone as its VM.

Premium SSD is the standard choice for production workloads and boot volumes. It comes in fixed size tiers from P1 (4 GiB) to P80 (32 TiB), and IOPS and throughput are tied to the tier you choose.

It supports OS disks, host caching, shared disks, zone-redundant storage and bursting.

Pick the smallest tier that meets your IOPS and throughput target, because you are billed for the full tier, not for the data stored.

Standard SSD is a low-cost SSD option for workloads that need steadier latency than HDD but not high IOPS. Typical fits are web servers, dev/test environments and lightly used enterprise applications.

Sizes follow the E-series naming (E1 to E80). It can be used as an OS disk and supports zone-redundant storage.

It is not designed for IOPS-hungry production databases; move those to Premium SSD, Premium SSD v2 or Ultra Disk.

Compared with Standard HDD it gives lower and more consistent latency for a modest price increase, which makes it the usual first upgrade for a dev/test VM that feels sluggish. Billing is by tier plus storage transactions.

Standard HDD is the cheapest managed disk, backed by magnetic drives. It fits backups, infrequently accessed data and non-critical dev/test machines where latency is not a concern.

Tiers use the S-series naming (S4 to S80). Latency is higher and more variable than SSD, and besides the tier price you are also charged per storage transaction.

Avoid it for databases or any interactive, latency-sensitive workload.

It also suits lab VMs that sit idle most of the time, or restored copies you only keep for a short while. If a workload on Standard HDD feels slow, moving it to Standard SSD is usually the cheapest first fix.

Host caching lets the VM's host keep recently used blocks in memory and local SSD, so repeated reads do not travel to remote storage. There are three settings: None, ReadOnly and ReadWrite.

Defaults are ReadWrite for the OS disk and None for data disks. Caching works for disks up to 4 TiB and is not available on Ultra Disk or Premium SSD v2.

Cache hits count against the VM's cached IOPS limit, not the disk's own limit.

Turn caching off for write-heavy disks such as database logs, because the cache adds overhead without helping.

A snapshot is a read-only, point-in-time copy of a managed disk. It exists as its own resource, so it survives even if the source disk or VM is deleted.

You cannot attach a snapshot directly. Instead you create a new managed disk from it and attach that. Snapshots are either full or incremental, and you are billed for the data they actually store.

az snapshot create -g rg-app -n snap-data01 --source data01 --incremental true

Take a snapshot before risky changes such as OS patching or a schema migration, so you can roll back quickly.

An incremental snapshot stores only the blocks that changed since the previous incremental snapshot of the same disk. The first one holds all used data; later ones are small and cheaper.

Each incremental snapshot can still be restored as a complete disk. You can delete an older one safely, because Azure keeps the data later snapshots depend on. They can also be copied to another region for disaster recovery.

Incremental snapshots are the type used by Azure Disk Backup.

Run them on a regular schedule, for example daily, and let a retention rule clear out the old ones.

Server-side encryption (SSE) encrypts managed disks, snapshots and images at rest using 256-bit AES. It is on by default, needs no configuration and has no performance penalty.

By default Microsoft holds the keys (platform-managed keys). You can switch to customer-managed keys stored in Key Vault, or add a second layer for double encryption.

SSE does not by itself cover the temporary disk or host cache; enable encryption at host for that.

Snapshots and images created from an encrypted disk stay encrypted too. With platform-managed keys, Microsoft handles key rotation, so you have nothing to operate.

A disk encryption set (DES) links managed disks to a customer-managed key in Azure Key Vault or Managed HSM. When a disk references a DES, SSE uses your key to wrap the disk's data encryption key.

The DES has its own managed identity, which must be allowed to wrap and unwrap keys (for example via the Key Vault Crypto Service Encryption User role). A DES can also be set to rotate to the latest key version automatically.

It is the building block for customer-managed keys and double encryption.

Bursting lets a disk briefly run above its provisioned IOPS and throughput to absorb spikes such as VM boot or a batch job. It is not meant for sustained load.

• Credit-based: Premium SSDs of 512 GiB and smaller (up to P20) earn credits while idle and spend them to reach about 3,500 IOPS and 170 MB/s; no extra charge.
• On-demand: Premium SSDs larger than 512 GiB (P30 and above) can reach up to 30,000 IOPS and 1,000 MB/s once enabled, with extra charges.

You can only grow a managed disk; shrinking is not supported. Increase the size in the portal or CLI, then extend the partition and file system inside the guest.

az disk update -g rg-app -n data01 --size-gb 1024
# Linux guest
sudo growpart /dev/sdc 1
sudo resize2fs /dev/sdc1

Many data disks can be expanded while attached, but crossing the 4 TiB boundary or resizing some OS disks requires deallocating the VM first. To get a smaller disk, create a new one and copy the data.

A shared disk is a managed disk that can be attached to several VMs at once, controlled by the maxShares property. It is meant for clustered software such as Windows Server Failover Clustering, SQL Server FCI and Pacemaker.

The cluster software must coordinate access using SCSI persistent reservations. Mounting a normal file system from several VMs without a cluster manager corrupts data.

Supported on Ultra Disk, Premium SSD v2, Premium SSD and Standard SSD. Standard HDD does not support sharing.

An ephemeral OS disk keeps the OS on the VM's local storage (cache or temp disk) instead of remote managed storage. There is no disk storage cost, latency is low, and reimaging is fast.

The trade-off is that state is not preserved. The OS is lost if the VM is deallocated or the host fails, so it fits stateless workloads such as scale set instances and AKS nodes.

The chosen VM size must have a cache or temp disk large enough for the OS image.

The practical impact is capacity planning. With unmanaged disks several busy VHDs in one storage account could hit the account's limits, a problem managed disks remove. Existing unmanaged disks should be converted with az vm convert (the VM is deallocated during the conversion).

Always check that a VM still using unmanaged disks has been converted, since the retirement means they are no longer supported.

Choose Premium SSD for boot volumes and cache-friendly workloads. Choose Premium SSD v2 when you need more IOPS than the size tier would give, without paying for unused capacity.

In practice, a database needing 20,000 IOPS on a modest data size usually costs less on Premium SSD v2 than on a large P-tier bought only for its IOPS allowance.

Both are data-disk only, have no host caching and are zonal. The usual rule is to start with Premium SSD v2 and move to Ultra Disk only when a single disk must exceed 80,000 IOPS or 1,200 MB/s.

Ultra Disk also lets you tune IOPS and throughput on a live disk, which is useful for workloads with predictable peaks such as month-end processing. Premium SSD v2 allows the same adjustments, but within its lower ceiling and with a free baseline that keeps small disks inexpensive.

Start with the workload's needs, then validate against VM limits and budget.

1. Does the disk hold the OS? If yes, only Premium SSD, Standard SSD or Standard HDD apply.
2. Measure required IOPS, throughput and latency (peak, not average).
3. Need above 80,000 IOPS or 1,200 MB/s on one disk? Choose Ultra Disk.
4. Need tunable IOPS and throughput for a database? Choose Premium SSD v2.
5. General production or cache-friendly workload? Choose Premium SSD.
6. Light or dev/test? Standard SSD; rarely used data? Standard HDD.

flowchart TD
A["Need a disk"] --> B{"OS disk?"}
B -->|Yes| C["Premium SSD / Standard SSD / Standard HDD"]
B -->|No| D{"Over 80k IOPS?"}
D -->|Yes| E["Ultra Disk"]
D -->|No| F{"Need tunable IOPS?"}
F -->|Yes| G["Premium SSD v2"]
F -->|No| H["Premium SSD or Standard SSD"]

Finally confirm the chosen VM size can actually deliver the performance.

With ReadOnly caching, reads are served from host memory or local SSD after the first access, while writes go straight to the remote disk. This lowers read latency and lets reads exceed the disk's own limit, bounded by the VM's cached limit.

With ReadWrite caching, writes are acknowledged from the cache first (write-back). That is fast but risky: if the host fails before data is flushed, uncommitted writes can be lost unless the application flushes properly.

sequenceDiagram
participant App
participant Cache as Host cache
participant Disk as Remote disk
App->>Cache: Read block
Cache-->>App: Hit, returned from cache
App->>Cache: Read new block
Cache->>Disk: Fetch block
Disk-->>Cache: Data
Cache-->>App: Data (now cached)

Typical guidance: ReadOnly for read-heavy data files, None for write-heavy or log disks.

Every VM size has its own caps on uncached and cached IOPS and throughput, in addition to each disk's limits. Real performance is the lower of the two, applied across all disks on the VM.

For example, a P40 disk allows 7,500 IOPS, but on a VM capped at 3,200 uncached IOPS you will never see more than 3,200. Attaching more disks to that VM adds capacity, not speed.

So size the VM and the disks together: add up the demand from every disk and compare it with the VM's published limits before choosing either.

When a workload slows down after a disk upgrade with no gain, a VM-level cap is the first thing to check.

Striping combines several disks into one volume so IOPS and throughput add up. On Windows use Storage Spaces with a simple layout; on Linux use LVM or mdadm RAID 0.

sudo pvcreate /dev/sdc /dev/sdd
sudo vgcreate datavg /dev/sdc /dev/sdd
sudo lvcreate -i 2 -I 64 -l 100%FREE -n datalv datavg
sudo mkfs.xfs /dev/datavg/datalv

Use RAID 0, not RAID 1 or 5, because Azure already keeps redundant copies of each disk. Use identical disk types and sizes, and remember the combined result is still capped by the VM size limit. Snapshots must be taken across all disks together to stay consistent.

Restoring is always a two-step job: create a new disk from the snapshot, then attach or swap it.

1. Create the snapshot of the source disk.
2. Create a new managed disk with the snapshot as its source.
3. Attach the new disk to a VM, or swap it in as the OS disk.

az snapshot create -g rg-app -n snap-data01-1013 --source data01 --incremental true
az disk create -g rg-app -n data01-restored --source snap-data01-1013 --sku Premium_LRS
az vm disk attach -g rg-app --vm-name vm01 --name data01-restored

A snapshot taken from a running VM is crash-consistent. For databases, quiesce the application or use VSS or Azure Backup to get application consistency.

Use ZRS when a workload must survive the loss of an entire availability zone without data loss. ZRS replicates the disk synchronously across three zones in a region and is available for Premium SSD and Standard SSD.

It is most useful with shared disks for clusters that span zones, such as SQL Server FCI or SAP ASCS, where the data must be reachable from VMs in different zones.

The cost is slightly higher write latency and price compared with LRS. If your application already replicates data itself (for example Always On availability groups), LRS disks in separate zones may be enough.

Azure Disk Backup uses a Backup vault and a backup policy. At each scheduled run it takes an incremental snapshot of the disk and keeps it in a snapshot resource group in your subscription, based on the retention rules.

The vault's managed identity needs two roles: Disk Backup Reader on the source disk and Disk Snapshot Contributor on the snapshot resource group. Restore creates a new disk.

This is different from Azure VM backup (Recovery Services vault), which backs up the whole VM through an extension and can give application-consistent points. Disk Backup is crash-consistent.

Test a restore early so you know the real recovery time, not just that backups succeed.

Both sit on top of default SSE. Encryption at host is the simpler choice when you want temp disk and cache covered with no agent inside the VM.

Encryption at host is enabled per subscription through a feature registration and then per VM. ADE needs the extension inside the VM, which adds a dependency to patching and image builds.

Exporting a disk generates a time-limited SAS URI. To control that, set the disk's networkAccessPolicy to one of AllowAll, AllowPrivate (through a disk access resource and private endpoint) or DenyAll.

az disk update -g rg-app -n data01 --network-access-policy AllowPrivate --disk-access myDiskAccess

Also restrict who can call Microsoft.Compute/disks/beginGetAccess/action with RBAC, and enforce the policy across the subscription with Azure Policy so new disks cannot be exported publicly.

A good baseline is DenyAll or AllowPrivate on production disks, with exports allowed only through a short, audited change window. Remember that a SAS URI is a bearer token: anyone holding it can read the disk until it expires or is revoked.

Use Azure Monitor metrics at both the disk and VM level. The most useful VM metrics are Data Disk IOPS Consumed Percentage and Data Disk Bandwidth Consumed Percentage (and the OS disk equivalents), plus queue depth.

A consumed percentage near 100% means throttling, and latency will rise. Create alerts on these metrics rather than on raw IOPS.

Inside the guest, confirm with iostat -x on Linux or the Avg. Disk sec/Read counter in Performance Monitor on Windows.

Typical alerts: IOPS or bandwidth consumed above 80% for 10 minutes, and queue depth that stays high. Compare the VM-level and disk-level graphs, because either layer may be the one throttling you. Keep the baseline from a healthy week so you can recognise change quickly.

Choose a disk when the application expects a local drive and needs predictable IOPS. Choose Azure Files when many machines must read and write the same file tree. Choose Blob for large objects accessed through APIs.

Cost and latency follow the same split: disks give low, predictable latency, Files is billed on shares and protocol features, and Blob is the cheapest per GiB but has no block-device semantics.

The Azure Disk CSI driver creates a managed disk whenever a PersistentVolumeClaim asks for one, attaches it to the node running the pod, and mounts it. AKS ships the classes managed-csi (Standard SSD LRS) and managed-csi-premium (Premium SSD LRS).

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 100Gi

Disks are ReadWriteOnce and zonal, so the pod must run in the disk's zone. Use volumeBindingMode: WaitForFirstConsumer so the disk is created where the pod lands. The node VM size limits how many disks can attach.

Delete the PVC and, depending on the reclaim policy, the disk is removed too. Set a Retain policy for data you cannot lose.

Use az disk update --sku (or the portal) to move between Standard HDD, Standard SSD and Premium SSD. The VM usually needs to be deallocated, or the disk detached, before the change applies.

az disk update -g rg-app -n data01 --sku Premium_LRS

Ultra Disk and Premium SSD v2 cannot be converted in place. To move to or from them, create a new disk of the target type and copy the data (for example with a file-level copy), then switch over. After conversion, billing follows the new SKU.

Also plan the maintenance window, because deallocating briefly takes the VM offline. Test the change on a copy first if the data is critical.

Premium SSD, Standard SSD and Standard HDD are billed by the provisioned tier, not by the data you store. A 100 GiB Premium SSD is billed as a P10 (128 GiB). Standard SSD and HDD also add per-transaction charges.

Ultra Disk and Premium SSD v2 bill separately for capacity, provisioned IOPS and provisioned throughput per hour. Snapshots are billed on the data they store, and on-demand bursting adds extra fees.

A disk keeps billing when its VM is deallocated or the disk is detached, so unattached disks are a common source of wasted spend. Reserved capacity can discount Premium SSD tiers.

1. Check the IOPS and bandwidth consumed percentage metrics. 100% means throttling.
2. Identify which limit is hit: the disk's, or the VM's cached or uncached cap.
3. Look at the I/O pattern. Small random I/O stresses IOPS; large sequential I/O stresses throughput.
4. Review host caching. Move read-heavy data to ReadOnly and keep logs at None.
5. Inspect queue depth and guest metrics (iostat -x or Performance Monitor).
6. Fix the bottleneck: resize the VM, move to a higher tier or Premium SSD v2, or stripe disks.
7. Rule out guest causes such as antivirus scans, misaligned partitions or a nearly full file system.

Always change one thing at a time and re-measure.

Take a P20: its baseline is 2,300 IOPS. While running below that it accumulates credits, and a spike can then draw them down toward 3,500 IOPS. Once the bucket is empty the disk falls back to baseline.

Neither mode raises the disk's sustained rate. If the workload needs more than baseline for long periods, resize the disk or move to Premium SSD v2 instead of relying on bursts.

A managed disk is an Azure Resource Manager object, but its data lives in Azure-managed storage as page blobs that you never see. With LRS, every write is stored in three synchronous copies inside one datacenter; with ZRS the copies are spread across zones.

The VM does not use a local drive. The host's storage client sends block I/O over the network to the storage cluster, and a write is acknowledged only after the replicas have durably committed it. This I/O is governed by the VM's disk limits rather than its network limits.

sequenceDiagram
participant VM as Guest VM
participant Host as Host storage client
participant R as Replicas (3 copies)
VM->>Host: Write block
Host->>R: Send to all replicas
R-->>Host: Durable commit
Host-->>VM: Write acknowledged

Host caching, bursting and throttling are applied in the host layer, before requests reach the storage cluster.

A disk is created from one of four sources: empty, a platform or custom image, a snapshot, or an upload. It then moves through states that you can read from the diskState property.

flowchart LR
A["Create (empty, image, snapshot, upload)"] --> B["Unattached"]
B --> C["Attached"]
C --> D["Snapshot / Backup"]
C --> B
B --> E["ActiveSAS (export)"]
E --> B
B --> F["Delete"]

• Unattached: exists but no VM uses it, still billed.
• Attached: in use. Resize, change caching, or change performance while attached (support varies by type).
• Reserved: attached to a deallocated VM.
• ActiveSAS / ReadyToUpload: export or direct upload is in progress.

Deletion is permanent unless you hold a snapshot or backup, so protect important disks before retiring them.

Two limits apply to every I/O: the disk's IOPS and throughput limit, and the VM's aggregate limit across all its disks. VM limits are published separately for cached and uncached I/O.

Reads that hit the host cache on a ReadOnly or ReadWrite disk consume the VM cached limit instead of the disk limit. Cache misses and writes to the disk count against the uncached limit. Ultra Disk and Premium SSD v2 have no cache, so they use only the uncached limit.

When requests exceed a limit, Azure does not drop them. They queue, so latency rises and queue depth grows. The consumed percentage metrics show how close each layer is. Bursting temporarily raises the ceiling at disk or VM level but does not remove it.

A shared-disk cluster uses one managed disk with maxShares greater than 1, attached to every cluster node. The cluster software (WSFC, SQL FCI, SAP ASCS or Pacemaker) controls access through SCSI persistent reservations.

1. Choose the disk type: Premium SSD or Standard SSD (ZRS available), Premium SSD v2 or Ultra Disk for higher performance.
2. Place nodes in different zones with a ZRS disk, or in one zone with LRS and a proximity placement group.
3. Set host caching to None, which shared disks require.
4. Add a quorum witness (cloud witness for WSFC) and an Azure Load Balancer for the client connection point.
5. For Pacemaker, configure the Azure fence agent so a failed node is truly isolated before failover.

Then test failover repeatedly. A cluster that was never failed over is not highly available, only hopeful.

Match each file type to the right disk and cache setting, then make sure the VM can carry the load.

• Disk type: Premium SSD or Premium SSD v2 for data and log; Ultra Disk if the log needs extreme low latency.
• Data files: a separate pool on ReadOnly cache (Premium SSD).
• Log files: a separate pool with caching None.
• tempdb: the local temp disk, which is low latency and does not need to persist.
• Striping: stripe several disks per pool with a 64 KB interleave and format volumes with a 64 KB allocation unit.
• VM size: pick one whose uncached and cached limits cover the combined demand.

Validate with a load test, and watch consumed percentage metrics once in production.

Use direct upload, which sends the VHD straight into a managed disk without an intermediate storage account. The VHD must be in fixed format.

1. Create an empty disk with --for-upload and the exact upload size (file size plus the 512-byte footer).
2. Grant write access to get a SAS URI.
3. Copy the VHD with AzCopy as a page blob.
4. Revoke access so the disk becomes a normal unattached disk.

az disk create -n uploaded01 -g rg-app --for-upload --upload-size-bytes 34359738880 --sku Standard_LRS
az disk grant-access -n uploaded01 -g rg-app --access-level Write --duration-in-seconds 86400
azcopy copy "disk.vhd" "SAS-URI" --blob-type PageBlob
az disk revoke-access -n uploaded01 -g rg-app

For many servers, Azure Migrate automates the replication and disk creation.

Verify the upload by attaching the disk to a test VM before decommissioning the source.

Deallocate: persistent disks stay attached and keep billing. The temporary disk and any ephemeral OS disk are lost, and the VM's compute charges stop.

Delete: the outcome is set per disk by the deleteOption property, either Detach (disk is kept) or Delete (disk is removed with the VM). Portal defaults and CLI defaults can differ, so check them.

Disks left behind are billed until removed. Find them by looking for disks with no owner:

az disk list --query "[?managedBy==null].{name:name, rg:resourceGroup, size:diskSizeGb}" -o table

Review that list regularly, and snapshot anything you are unsure about before deleting.

Once a VM is gone, its temporary disk contents cannot be recovered, so copy anything valuable off it beforehand. Setting deleteOption to Detach on data disks is the safer default.

Premium SSD ties IOPS to size, so reaching a performance target can force you to buy far more capacity than you need. Premium SSD v2 separates the two, so you pay for what you actually provision.

Example: a database needs 500 GiB and 10,000 IOPS. On Premium SSD, 10,000 IOPS means moving up to a P60 (8 TiB, 16,000 IOPS) because a P50 tops out at 7,500. On Premium SSD v2 you provision 500 GiB and add roughly 7,000 IOPS above the free 3,000 baseline.

Check current pricing for your region, because the saving depends on the ratio of IOPS to capacity. The trade-offs are no host caching, no OS disk use and no bursting, so cache-friendly workloads can still favour Premium SSD.

Start from the RPO and RTO the business needs, then layer protections, since each covers a different failure.

Azure Site Recovery replicates the VM's disks to replica disks in a target region and gives recovery points for failover. Confirm which disk types and features your scenario supports, then run regular test failovers. ZRS does not protect against deletion, corruption or loss of a whole region.

Document the failover order, since databases, then app servers, then web tiers recover in sequence. A written runbook beats memory during an incident.

Store the key in Key Vault, reference it from a disk encryption set and enable automatic key rotation. When a new key version is created (manually or by a Key Vault rotation policy), the DES picks it up on its own.

az disk-encryption-set update -g rg-app -n des01 --key-url https://myvault.vault.azure.net/keys/diskkey --enable-auto-key-rotation true

Rotation changes only the key encryption key. Azure re-wraps each disk's data encryption key, so no data is re-written and VMs keep running.

The vault must have soft delete and purge protection. Never disable or delete the key while disks use it, or those disks (and their VMs) become inaccessible.

Test the rotation on a non-production DES first, and set a Key Vault alert for keys nearing expiry, so a lapsed key never surprises you.

Neither is better in general; they solve different scale problems. Managed disks are the simple default: each disk is provisioned on its own and attached natively to one VM. Azure Elastic SAN is a pooled block storage service where capacity and performance are provisioned for the whole SAN and shared across its volumes.

Choose managed disks for most VM workloads. Consider Elastic SAN when you are consolidating many volumes and want to avoid stranding capacity and performance on individual disks.