Quartz 5

Lab: VM lifecycle, disks, encryption, and moves

Properties1
tagslab, az-104, compute, vm, disks, encryption

3 min read

Lab: VM lifecycle, disks, encryption, and moves

Outcome

Create a disposable VM through portal and CLI, attach and resize a data disk, resize the VM safely, and distinguish a same-tenant resource move from a regional migration. Test encryption-at-host eligibility without changing production data.

Do

  1. Create a small Linux VM in a disposable resource group through the portal; capture the validation summary, size, image, disk, NIC, and network choices. Create an equivalent second VM with Azure CLI and connect only through the approved training path.
  2. Create a managed data disk, attach it, initialize/mount it in the guest, create evidence.txt, then resize the disk through the control plane and expand the guest partition/filesystem. Verify size before and after.
  3. Stop and deallocate the CLI VM before changing its size when the selected resize requires it. Capture the size-availability result, resize to a supported test size, start it, verify workload access, then return to the original size if appropriate.
  4. In the same tenant, validate a move to a second training resource group and perform it only after dependency/move validation succeeds. For a different region or subscription, create an export/redeploy or replication migration plan instead; a resource-group move does not change region.
  5. In a separate disposable plan, check region/VM-size eligibility for encryption at host. Create the Key Vault, disk encryption set, and supported VM only if eligible. Record the unsupported-size or incompatible Azure Disk Encryption condition if encountered; do not try to enable it on a VM that currently or previously used Azure Disk Encryption.

Verify

Capture portal and CLI create evidence, disk attach/mount/resize output, deallocated/resize/start state, move validation and resource ID, and encryption-at-host eligibility/result. You should now understand: a managed disk has both Azure and guest OS steps; VM resize changes compute capacity; a move and a regional migration are different operations; encryption-at-host requires an eligible design.

Break and fix

  1. Try to resize a mounted disk only in Azure; diagnose the unchanged guest partition and expand it safely.
  2. Attempt a move with an unsupported dependency or target; read validation output, correct the plan, and revalidate instead of forcing it.
  3. Select an ineligible size for encryption at host; document the compatibility failure and choose a supported disposable VM rather than weakening encryption requirements.

Scenario practice

  1. Configure: Choose VM, disk, availability, and encryption requirements for a stateful workload.
  2. Diagnose: A resize fails or the OS still sees the old disk size. Which Azure state, size availability, partition, and filesystem evidence do you inspect?
  3. Distinguish: Contrast resource-group move, subscription move, regional migration, disk resize, and VM resize.

Clean up

Detach/delete training disks only after confirming they hold no needed evidence. Delete VMs, encryption set/Key Vault only after dependent resources are gone, and both training resource groups.

Sources and re-audit

Re-audit when VM/disk compatibility or move support changes.

azure-vm · managed-disks · vm-sizes · vm-move · vm-encryption-at-host · All labs

Graph View

Backlinks