Deploy and manage Azure compute resources
Virtual Machine Lifecycle, Sizing, Disks, and Moves
CoreCreate and operate VMs, sizes, disks, encryption at host, and supported resource or regional moves.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
VM administration joins compute capacity, storage layout, encryption, dependencies, and placement; a change that fits one layer can still fail because another layer is unsupported.
Must Know
- VM creation coordinates image, size, authentication, network interface, disks, region, availability choice, and management settings.
- Resize changes the compute shape of one VM and can require restart or deallocation depending on host capacity and target size.
- The OS disk contains the operating system; data disks provide separate persistent capacity and have independent size, tier, caching, and attachment choices.
- The current AZ-104 objective explicitly requires encryption at host, which protects temporary disks, disk caches, and flows between the compute host and Storage service; Azure Disk Encryption (ADE) is a separate older guest-based approach, and Microsoft has announced its retirement.
- Resource-group or subscription moves are management-plane moves within a region, while regional relocation uses supported migration tooling and compatibility checks.
Compare and Distinguish
- OS disk vs data disk: boot volume required by the VM vs attachable persistent application or data volume.
- Resize vs scale out: give one VM a different CPU or memory shape vs add more VM instances to share demand.
- Resource-group/subscription move vs regional move: change administrative resource ID path vs recreate or move resources into another Azure region.
- Encryption at host vs Azure Disk Encryption: platform host protection vs the separate guest-based ADE approach that uses BitLocker or DM-Crypt.
- Encryption at host vs storage-account encryption: VM-host coverage for temporary/cache paths vs encryption of data stored by Azure Storage services.
Scenario examples
- Scenario: One VM needs more memory but no additional instances. Think: Select a supported larger size and plan for any required restart or deallocation.
- Scenario: Application data must persist independently of the boot volume. Think: Attach and format a managed data disk rather than expanding only the OS disk.
- Scenario: A VM must relocate to another region. Think: Validate every dependent resource and use supported regional move or migration tooling, not a resource-group move.
Exam traps
- Changing the resource group does not move a VM to a new Azure region.
- A larger disk allocation does not automatically expand the guest operating system partition or filesystem.
- Never substitute Azure Disk Encryption when a scenario specifically requires encryption at host; Microsoft recommends encryption at host or other platform options for new VMs because ADE retirement has been announced.
Key takeaways
- Treat a VM as a dependency graph of compute, disks, NIC, identity, region, and availability settings.
- Distinguish vertical resizing, disk changes, administrative moves, and regional migration before choosing an operation.
How it works
- The VM resource references a compute size, OS profile, NIC, managed disks, and optional extensions that Azure coordinates during lifecycle operations.
- Resize or move prechecks examine target platform capacity and every associated resource rather than changing an isolated label.
Objects and administrative surfaces
- VM — size, image, OS settings, identity, extensions, availability placement, encryption at host, and lifecycle state.
- Managed disk — OS or data role, capacity, performance tier, caching, encryption, snapshot, and attachment state.
- Resource group, subscription, and region — move readiness, dependencies, quotas, provider support, and destination networking.
When to use it
- Use a VM when the workload requires guest OS control or software that does not fit a managed application platform.
- Use separate data disks to isolate application data lifecycle and performance from the OS disk.
Security and governance implications
- Prefer managed identities and secure administrative access, patch the guest, and encrypt required host and disk paths.
- Control snapshots and disk exports because they can expose the full contents of persistent volumes.
How to reason about this
- For a VM operation failure, inspect power state, quota, size availability, disk and NIC dependencies, locks, Policy, and activity-log error.
- For guest storage symptoms, distinguish Azure disk allocation and attachment from partition, filesystem, mount, and caching state inside the guest.
More detail
- Create VMs through portal or automation and interpret how images, sizes, disks, authentication, networking, and availability interact.
- Size availability, quota, disk compatibility, and encryption support are region- and configuration-dependent and must be checked.
Ready for the quiz?
- Which VM components must be planned before creation?
- Why can increasing a managed disk leave the guest filesystem unchanged?
- Which operation is required when the destination is another region?
Related objectives
- D3.2.S1 — Create a virtual machine
- D3.2.S2 — Configure encryption at host for Azure virtual machines
- D3.2.S3 — Move a virtual machine to another resource group, subscription, or region
- D3.2.S4 — Manage virtual machine sizes
- D3.2.S5 — Manage virtual machine disks