1) What an Azure “disk” is#

An Azure VM uses virtual hard disks (VHDs) presented to the guest OS as block devices.

The common disk categories you manage on a VM:

OS disk: holds the operating system.

Temporary disk: ephemeral storage (not durable; used for swap/temp depending on OS and config).

Data disks: durable disks you attach for app/data (databases, file shares, logs, etc.).

2) Managed vs. unmanaged disks (important exam + real-world difference)#

Managed disks (modern/default): Azure manages the underlying storage accounts and durability/availability aspects for you. You manage a first-class resource called Disk (RBAC, snapshots, backup integration, etc.).

Unmanaged disks (legacy/classic): VHDs live in a storage account you manage, increasing operational overhead and making scaling/availability management more DIY. (Most environments should avoid new unmanaged designs today.)

Managed disk types and the ability to change disk performance tiers are documented under Azure Disk Storage. ()

3) Disk performance tiers (what to choose and why)#

Azure Disk Storage offers tiers optimized for different workloads:

• Ultra Disk: highest performance/lowest latency (heavy OLTP, extremely IO-sensitive workloads). ()
• Premium SSD / Premium SSD v2: production performance workloads. ()
• Standard SSD: dev/test, web servers, lighter enterprise workloads. ()
• Standard HDD: lowest cost; backup/non-critical workloads. ()
• Key constraint: disk throughput/IOPS can be limited by VM size, so “fast disk + small VM” may still bottleneck (common gotcha for databases).

What the demo actually did (step-by-step, conceptually)#

A) Create a managed disk resource#

In the portal:

• Create Managed Disk
• Pick region, size (GB), and tier (Premium/Standard/etc.)
• Choose redundancy (commonly LRS for many single-region patterns; higher redundancy depends on scenario)
• Review encryption settings (platform-managed by default; CMK optional)
• Disk tiers and management are covered in Azure Disk Storage docs. ()

B) Attach the disk to an existing VM#

Portal path (typical):

• VM → Disks → Attach existing disk (or create+attach)
• Attaching makes the disk visible to the guest OS, but the disk is empty/unformatted, so the OS won’t “use” it until you partition + format + mount it.

C) Initialize the disk inside Linux (partition, format, mount)#

Typical Linux workflow:

• Identify the new device (often /dev/sdc, /dev/sdd, etc.)
• Partition it
• Create a filesystem
• Mount it to a directory (optionally persist via /etc/fstab)
• Microsoft’s Linux VM guidance shows the exact idea (use lsblk, partition, mkfs, mount). ()

Example commands (your transcript used parted + mkfs.xfs, which is very common):

• lsblk

• Partition (example with parted; replace /dev/sdd with your new disk)

• sudo parted /dev/sdd --script mklabel gpt mkpart primary 0% 100%

• Format (XFS example)

• sudo mkfs.xfs -f /dev/sdd1

• Create mount point + mount

• sudo mkdir -p /datadrive
• sudo mount /dev/sdd1 /datadrive

• Verify

• lsblk
• The architecture-center guide demonstrates the same lifecycle: discover disk → partition → create filesystem → mount. ()

Important troubleshooting insight from the demo#

“Permission denied (publickey)” when SSH’ing#

That happened because the VM was created with SSH key auth, but the user tried to connect without the right private key (or from an environment that didn’t have it available).

Common fixes:

Use the correct private key (best).

Or reset credentials / re-inject SSH keys using supported Azure mechanisms (commonly via VM agent/extension tooling). A Microsoft sample shows using the VMAccess** extension** to add/modify users/keys on Ubuntu. ()

If reset operations fail, a frequent root cause is VM agent / extension health (walinuxagent, extension failures, etc.). ()

Deeper understanding + best practices (exam-friendly)#

1) Plan disks around the workload#

• Databases: isolate data/log/temp onto separate disks when needed; pick Premium/Ultra when latency matters.
• Apps/logs: standard SSD often fine for many internal apps.
• “Cheap storage” for non-critical: standard HDD.

2) Mount persistence#

Mounting is temporary across reboot unless you add an /etc/fstab entry (Linux). In production, always validate:

• correct UUID/label usage
• boot doesn’t hang if disk missing (use nofail where appropriate)

3) Security & encryption posture#

Storage encryption at rest is typically on by default for Azure-managed storage; for stricter compliance, consider customer-managed keys (CMK) (often with Key Vault) for disks depending on requirements. ()

4) “Shared disk” is a special case#

You saw a “shared disk” toggle in the UI. Shared disks are for cluster-style scenarios (multiple VMs attaching to the same disk) and come with design constraints—don’t enable it unless you’re implementing a supported clustering pattern.

Hands-on: Attach, Mount, and Resize a Managed Disk#

Goal: Add a data disk to a Linux VM, mount it persistently, then resize it.

1. Open the VM and choose Disks > Create and attach a new disk.
2. Set name az104-linux-01-data01, size 32 GiB, and disk type Premium SSD or Standard SSD for labs.
3. Save the VM disk configuration.
4. Connect to the VM with SSH.
5. Identify the new disk:

lsblk

6. Partition and format the disk:

sudo parted /dev/sdc --script mklabel gpt mkpart primary 0% 100%
sudo mkfs.xfs -f /dev/sdc1

7. Mount it:

sudo mkdir -p /data
sudo mount /dev/sdc1 /data
df -h

8. Persist the mount with the UUID:

sudo blkid /dev/sdc1
sudo cp /etc/fstab /etc/fstab.bak
echo "UUID=<uuid> /data xfs defaults,nofail 0 2" | sudo tee -a /etc/fstab
sudo mount -a

9. In the portal, resize the disk from 32 GiB to 64 GiB.
10. Back on the VM, rescan and grow the filesystem:

sudo partprobe
sudo xfs_growfs /data
df -h

11. Reboot and confirm /data mounts automatically.

Hands-on: Snapshot and Restore a Managed Disk#

1. Stop write-heavy applications on the VM or schedule a maintenance window.
2. Open the managed disk and choose Create snapshot.
3. Name it az104-linux-01-data01-snap.
4. Create a new managed disk from the snapshot.
5. Attach the restored disk to a test VM.
6. Mount it read-only if you only need validation.
7. Confirm the expected files exist.
8. Delete the test disk and old snapshots when finished.

Reference documentation (official / primary)#

• Azure Disk Storage overview and disk types/performance tiers ()
• Linux VM guidance showing data-disk partition/format/mount workflow ()
• VMAccess extension sample (adds/modifies users/SSH keys on Ubuntu) ()
• Troubleshooting reset/password/agent/extension issues (Microsoft Q&A) ()
• If you want, paste the next transcript (e.g., VM Scale Sets / Availability Sets / Backup) and I’ll summarize it in the same format.