A virtual machine change can look harmless in a management portal and still fail because its disk, availability placement, network interface, identity or recovery configuration was not considered. Imagine a payroll application’s VM is hitting a memory limit.
The team wants to resize it, move its management ownership to a different resource group and leave a defensible rollback path. In Microsoft AZ-104 administration, these are three separate decisions: compute capacity, resource organization and business recovery. Doing one successfully does not establish that the other two are safe.
Microsoft’s AZ-104 exam objectives explicitly cover virtual machine creation, host encryption, sizes, disks, availability sets and zones, scale sets, and moves between resource groups, subscriptions and regions. A useful administrator-level exercise therefore begins with the actual VM dependencies and finishes with evidence that the workload still functions. The following is a proposed practice scenario, not a record of a deployment that was run.
Inventory the VM before changing anything
Start with a single application VM called vm-payroll-test in a disposable resource group. Record the resource ID, subscription, region, zone or availability-set membership, VM size, operating system, image, OS and data disks, disk encryption configuration, NIC, private address, NSG, identity assignments and backup protection.
The purpose is to know which components the change touches and which it does not. A VM resize generally does not turn a data-disk mount into a valid one, and moving a management resource does not automatically rewrite a hard-coded resource ID in a monitoring script.
Separate the Azure control plane from the guest operating system. Azure can report a VM as Running while the payroll service is stopped, an attached disk is not mounted or the application cannot reach its database. Capture both the Azure resource status and an application check, such as a known endpoint and an authorized read-only database request. Those two baselines will expose different failures later.
Also identify who will execute the change and under what role. The VM’s managed identity governs the workload’s access to other services; it does not automatically grant the human operator permission to resize or move the VM. Record the operator’s Azure RBAC scope independently of the service principal used by the application.
Choose a size from measured demand and the destination’s limits
Use memory pressure, CPU saturation, storage throughput, network performance and observed peak traffic to justify a target VM family and size. A CPU-heavy batch processor and a memory-bound transactional service might need different sizes even when their current monthly costs are similar. Confirm that the target SKU is supported in the region and zone and that subscription quota and capacity constraints will permit the requested change. Do not assume a size available in one region is available in another.
Before the approved maintenance window, record the original size, planned size, expected interruption and rollback size. Some resizes require a stop or deallocation, and the guest may need time to start or remount services afterwards. The safer success criterion is a before-and-after application test with a measured performance reason for the change, not merely a portal message that the resize succeeded.
Protect disks and understand what encryption does not solve
Distinguish OS disks from data disks and managed disk protection from guest-level application consistency. A disk snapshot is useful for some restore and investigation tasks, but it is not automatically a tested application-consistent recovery point.
If the VM hosts a stateful service, check the application’s supported backup procedure before changing disk layout or encryption settings. Size and performance decisions also affect disk throughput limits; a larger VM does not cure a data disk that is constrained by its own provisioned tier or I/O pattern.
Azure Storage encryption of managed disks at rest and encryption at host cover related but distinct protection boundaries. Host encryption has prerequisites that depend on the selected VM size, region and configuration. Determine the current setting, supported target and organizational encryption requirement before touching it. An encryption flag does not replace identity controls, backups, private networking or a tested restore path.
As part of the change request, identify the approved recovery point and the owner who can restore it. Choose Azure Backup vault and recovery controls according to policy and recovery requirements; a successful scheduled job is useful evidence, but only a restore rehearsal demonstrates that the business workload can return to service.
Understand the failure domain before selecting availability placement
An availability set helps suitable VMs avoid certain shared hardware and maintenance failure conditions through fault and update domains. Availability zones represent separate physical locations within a supported region. They are not synonyms and neither automatically solves single-VM application failure. If the goal is higher service availability, first determine whether the application can run on more than one instance, whether shared state is resilient, and how clients will be directed to healthy instances.
A Virtual Machine Scale Set can manage multiple instances under a desired configuration and scaling policy, but its utility depends on the application’s ability to scale and recover safely. A stateful server with a single writable local database is not made highly available merely by duplicating its VM definition. When traffic needs distribution, Azure Load Balancer and Application Gateway address different traffic layers. Choose based on transport, HTTP routing, TLS and health requirements, not a generic preference for a particular Azure service.
Do not confuse a management move with regional migration
Moving a supported VM and its dependencies to another resource group changes its Azure resource ID, even when the VM remains in the same physical region. Microsoft’s resource-move guidance explains validation, required dependent resources, and temporary locks on both source and destination resource groups during the operation. Existing workloads can remain running while management changes are locked; scripts, dashboards and references containing the old resource ID may still require updates. Read-only locks and unsupported dependencies can block the move altogether.
A move between subscriptions adds requirements involving tenant alignment, permissions, policies, quotas and target scopes. Role assignments, policies and tags inherited from the previous resource-group context should not be assumed to apply identically at the destination. Before acting, inventory dependencies and examine the target governance scope; then run Azure’s validation and resolve the reported blockers. The right response to a move validation failure is not to delete resources indiscriminately until the move is allowed.
A move to another Azure region is a different operation. The ordinary resource-group/subscription move does not change the resource’s physical region. Depending on resource type and support, Azure Resource Mover or a supported recovery or rebuild process may be appropriate. Expect to plan destination capacity, networking, data protection, cutover and verification. Treat a regional move as a migration with its own rollback and data consistency requirements.
Verify network access and guest health after the control-plane change
After a resize or move, check network resolution and the full path used by application clients. A successful VM resource operation does not prove that the database port is reachable or that the effective NIC and subnet security rules match the new operating context. Follow the actual source and destination through DNS, routing, NSG effective rules, service authorization and guest firewall. If the service fails, separate an Azure platform issue from an operating system or application failure before changing access permissions.
Use a compact verification record rather than only a completion screenshot:
| Observed symptom | Evidence to check | Safe next decision |
|---|---|---|
| Resize completed, service still slow | Guest process metrics, disk limits, memory pressure, dependency latency | Find the actual bottleneck before resizing again |
| VM shows Running, payroll endpoint fails | Application process, guest logs, mounted data disks, backend connection | Repair or roll back the affected guest or application layer |
| Resource-group move rejected | Move validation, dependency list, locks, target permissions and policy | Resolve the named blocker; do not bypass governance |
| Monitoring breaks after a successful move | Stored resource IDs, role scopes, alert targets, dashboards and scripts | Update and retest references to the new resource ID |
| Cross-region request lacks a supported path | Resource Mover support, destination SKU/quota, data and network plan | Design a documented migration instead of treating it as a group move |
Finish with a change receipt that another administrator can audit
For the payroll test VM, the minimum useful receipt states the original resource ID and size, approved new size and scope, identified disk and network dependencies, expected interruption, backup reference, operation result, observed application health, and what remains to be checked. If a live operation was not performed, label all outcomes as expected results rather than reporting them as measurements. Preserve the previous configuration and the approved backout route until the application owner confirms recovery.
The administrative skill is not memorizing that Azure has resizes, disks, zones and move commands. It is distinguishing which boundary each operation changes, predicting what it leaves unchanged, and proving that business service continues to work afterwards. That decision process remains useful even when the portal layout, available VM families or migration features change.