A virtual machine can run a critical workload for months without anyone checking whether its disk tier still fits the demand or whether its data can be moved safely. Then a performance issue or security requirement triggers an urgent change: resize a data disk, enable encryption at host, move the VM to another subscription or relocate it to a different region. These are not interchangeable operations, and each has different prerequisites and failure modes.
Resizing a VM’s disk, moving its resource group and relocating a workload to another Azure region have different failure modes. A disk change must be recognized by the guest operating system; a logical move must satisfy resource dependencies and policy; a regional relocation needs a data and application migration plan. These are practical Microsoft AZ-104 compute decisions, not interchangeable portal operations. VM availability and scale sets addresses fleet-level resilience, while Backup and Site Recovery addresses recovery paths. Encryption at host, key permissions and service restart behavior still need their own post-change checks.
A managed disk has more decisions than capacity
Managed disks abstract much of the storage-account provisioning work, but the administrator still chooses disk class, size, performance characteristics and applicable redundancy. A transaction-heavy database and a lightly used web server do not need identical disk performance. Compare throughput, IOPS, latency needs and supported VM/disk combinations rather than choosing solely by nominal gigabytes.
A disk resize may increase capacity but not automatically deliver the application-level benefit until the operating system and file system recognize the change. Similarly, selecting a faster disk tier cannot repair a poorly tuned query or a network bottleneck. Measure actual storage latency and queue behavior before altering expensive infrastructure.
Record disk identity and attachment. A VM may have an OS disk, data disks, a temporary disk and cached data. Each has different durability and recovery expectations. A temporary disk must not be treated as permanent storage simply because an application can write to its path.
Compare server-side encryption and encryption at host
Azure managed disks are encrypted at rest through server-side encryption by default. Platform-managed keys provide the standard baseline; customer-managed key scenarios use supported disk encryption configurations and key-management arrangements. Encryption at host extends protection to temporary disks and host caches, encrypting data at the VM host before it is persisted to storage.
Those features should not be collapsed into a statement that “Azure encrypts every part of the VM identically.” They protect different segments of the path and have deployment restrictions. Encryption at host support depends on VM size, disk combination and region; administrators should check current prerequisites before enabling it on production machines.
An existing VM may need deallocation and reallocation for certain encryption-at-host changes to take effect. That can affect availability and scheduling. Plan a controlled maintenance window, verify platform compatibility and confirm encryption status after the operation. Avoid treating an encryption checkbox change as a harmless metadata edit when it can require host placement changes.
Key ownership changes the operational risk
Customer-managed keys can help an organization control aspects of encryption key governance, but they also create dependencies on the key store, access permissions and rotation procedures. A VM whose disk can no longer access the required key may be unusable even when compute and storage are healthy. Know the supported key access model and recovery path before adopting it.
For shared teams, roles that manage a VM do not necessarily imply unrestricted key-management authority. The scope considerations in Azure RBAC and role assignments help separate disk operations from changes to sensitive key material. Track who is authorized to rotate, revoke or restore keys and how emergency recovery would work when a policy change disrupts access.
Protecting data at rest is one part of defense in depth. Backups, authorized runtime access, network policy and logging still matter. A technically encrypted disk does not stop an authorized application from reading data and exfiltrating it, and a backup restored without valid access controls can reintroduce a security exposure.
Resource-group and subscription moves have prerequisites
Azure Resource Manager supports certain resource moves between resource groups or subscriptions when prerequisites are met, but a VM does not always move alone. It may depend on network interfaces, managed disks, availability constructs and other associated resources. Locks, policy, resource type restrictions and tenant boundaries can block or complicate the operation.
Confirm the supported resource set before the move. The destination subscription may have different quotas, policies and inherited role assignments. After moving, test the VM’s network path, disk attachments, monitoring and backup configuration as appropriate. A successful resource move can leave operational assumptions broken even if Azure reports that the transfer completed.
Do not assume a resource-group move changes a VM’s virtual network attachment or geographic location. Moving to a new VNet often requires reconstructing the VM with the appropriate interface and disk strategy, while cross-region relocation follows a distinct supported migration or recovery route. Plan these as separate projects with their own acceptance checks.
Moving regions is not moving between folders
A region move affects the physical placement of compute, data and dependencies. That makes it materially different from a logical resource-group reassignment. Administrators must address destination VM size availability, disk compatibility, replication or copying, networking, DNS, data residency and an acceptable downtime window.
A workload with an attached database, private endpoints and monitoring agents may require several coordinated changes before it becomes useful in the new region. It is not sufficient to recreate the VM and declare the migration complete. Test application integrity, network access, credentials, alerting and dependent services through the final hostname or client path.
Site Recovery and backup can supply supported replication and restoration mechanisms for selected scenarios. That does not mean Site Recovery is automatically the right tool for every planned migration. Compare the purpose—disaster failover, clean rebuild, tenant move or region relocation—before choosing an operational method.
Snapshots and backups protect different moments
A disk snapshot can capture a point-in-time representation useful for supported recovery or duplication workflows, while a scheduled backup policy usually adds retention, management and restore capabilities across a longer period. Neither should be presented as a substitute for application-consistent protection when the workload requires it.
A database may be writing across multiple disks. Taking unrelated disk copies without coordinating the application can yield an inconsistent restore even when each disk image is individually complete. Where supported, use application-aware recovery methods and test the restored service rather than relying solely on a successful snapshot creation event.
The restore plan should specify identity, encryption keys, network placement and application dependency versions. A disk restored into the wrong environment may be both inaccessible and insecure. Rehearse a representative recovery operation and record time to usable service, not simply time to create storage resources.
Change management is part of VM reliability
A VM resize, disk change or encryption adjustment may interact with availability placement and scaling. Before scheduling the operation, consider the workload redundancy described in VM availability and scale sets. A server that is the only node in a business-critical application needs a different maintenance plan from one member of a tested redundant fleet.
Use preflight checks to confirm platform support, resource quotas and subscription policy. Record the original VM size, disk configuration, encryption state, attached network resources and current backups. Define a post-change test for operating-system health, required application endpoints, storage performance and telemetry.
Use Bicep and ARM deployments for repeatable resource definitions, but not every migration can be expressed as an in-place template update. Some changes require an orchestrated sequence and an explicit cutover. Automation should preserve operator visibility into the effect and rollback plan.
Practice the decision, not a memorized sequence
An AZ-104 scenario may ask for more disk performance, stronger protection of temporary storage, relocation to another subscription or recovery in a second region. The correct response depends on which property is missing. More replicas do not repair an undersized disk; a disk snapshot does not change the VM’s region; encryption at host does not confer storage access permissions.
Use a single workload to test each decision deliberately. Inspect disk metrics and size, compare server-side encryption to host encryption, review a possible subscription move and map a regional recovery runbook. Storage redundancy and transfers belong in availability planning, but storage replication does not replace tested restore points or managed-disk protection.
The administrator’s outcome is a VM that remains supportable after the change. Record the reason, prerequisites, observed result and remaining risk so another operator can explain what was altered and why. This is the practical skill beneath AZ-104 disk and VM management questions: separate configuration, placement, protection and recovery before choosing the mechanism.
Record the dependencies before approving maintenance
A storage operation that affects one VM may have consequences elsewhere. A disk encryption change can depend on key permissions; a VM move can change monitoring subscriptions and inherited policy; a size change may change available temporary storage or networking performance. Build a dependency map covering disk, network interface, backup policy, identity and the service that consumes the VM. This prevents the common mistake of reviewing only the resource being clicked in the portal.
Post-change checks should be purposeful. After a disk resize, confirm that the operating system sees usable capacity and the application behaves normally. After a move, test management and data access from the actual user path. After an encryption update, verify the reported state and the ability to restart or recover with the configured key path. A migration is complete only when the workload is usable and the supporting controls still work.