Virtual machine administration remains a core part of the AZ-104 compute domain. The current blueprint includes creating VMs, configuring encryption at host, moving VMs between resource groups, subscriptions, or regions, managing sizes and disks, deploying to availability zones and availability sets, and working with Virtual Machine Scale Sets. The AZ-104 exam expects candidates to operate these resources, not merely describe virtualization.
A good way to study VM questions is to separate lifecycle, availability, storage, security, and scale. Many distractors are valid Azure features but solve a different VM problem. The scenario usually contains one operational requirement that should determine the design.
Create the VM around workload constraints
VM creation involves more than selecting an image and clicking Create. The administrator must consider region, availability design, size, disk requirements, network placement, identity, and management expectations. Choices made at deployment can affect whether the VM can meet performance or resilience requirements later.
Exam questions may give CPU, memory, or workload clues that point toward a size family or resizing action. The important skill is not memorizing every SKU; it is understanding that VM size controls available compute resources and can have dependencies such as region availability or supported features.
If the workload will be deployed repeatedly, connect VM creation to infrastructure-as-code objectives elsewhere in the compute domain. ARM templates or Bicep can make deployment repeatable and reduce configuration drift.
Manage disks as independent operational resources
OS and data disks have their own performance and lifecycle considerations. Administrators may need to add, resize, or manage disks without rebuilding the entire VM. Storage performance should match the workload rather than defaulting to the cheapest or most expensive disk type.
Disk configuration also affects backup, encryption, and migration planning. A move or recovery operation may involve dependencies that extend beyond the VM object itself. Before changing a production VM, identify which disks are attached and what protection exists for the data they contain.
This is another place where the exam rewards precise scope: a disk problem does not necessarily require a VM replacement, and a VM sizing problem does not necessarily require changing its storage architecture.
Use availability zones and availability sets for different failure models
Availability zones distribute resources across physically separate zones within a supported region, while availability sets are designed to spread VMs across fault and update domains within a datacenter-level availability construct. The requirement should determine which model is appropriate.
Do not select a high-availability feature simply because the scenario mentions production. Ask what failure the organization wants to tolerate and whether the application itself can use multiple instances. One highly available VM resource does not automatically make a single-instance application resilient to every failure.
Networking, storage, and application dependencies must align with the availability design. A multi-VM architecture can still have a single point of failure elsewhere.
Use VM Scale Sets when the workload needs a managed fleet
Virtual Machine Scale Sets are designed for groups of VMs that need consistent configuration and the ability to scale. They are different from manually creating several unrelated virtual machines. A scale set is appropriate when the application can run across multiple instances and the organization benefits from coordinated instance management.
Scaling should be tied to workload signals and capacity requirements. Adding instances can improve throughput, but stateful workloads may need additional design to keep data or sessions from depending on one machine. The exam may combine scale-set choices with load balancing or monitoring concepts.
Operational consistency is a major benefit. When the desired configuration changes, manage the fleet as a unit rather than treating every instance as a unique server that must be repaired by hand.
Protect hosts and administrative access
The current objectives explicitly include encryption at host. Understand that this control protects data handled by the VM host infrastructure and is part of a broader encryption strategy. It does not replace guest operating-system security, disk permissions, network controls, or identity management.
Administrative access should also be planned. Network security groups, Bastion, private addressing, and role assignments may determine who can reach and manage a VM. If a user cannot connect, distinguish Azure resource authorization from network reachability and guest operating-system authentication.
That layered troubleshooting approach avoids broad changes such as opening inbound access or granting Owner when the actual problem is limited to one control plane.
Move VMs only after checking dependencies
AZ-104 includes moving a VM to another resource group, subscription, or region. These are not identical operations. Resource-group and subscription moves preserve the idea of the same Azure resource under a different administrative boundary, while regional movement is a larger relocation problem with additional dependencies and planning.
Before a move, inspect attached resources, network dependencies, policies, role assignments, and any services that reference the VM. A move can change governance context because the destination scope may inherit different policy or RBAC assignments.
For exam scenarios, identify the requested destination and reason for the move. Do not assume one generic “move” command satisfies every cross-scope or cross-region requirement.
Connect VM operations to monitoring and recovery
Virtual machines do not end at deployment. Azure Monitor Insights, metrics, logs, alert rules, backup, and Site Recovery appear in the AZ-104 monitoring domain and can be part of a VM operational scenario. A capacity problem may require monitoring before resizing; a resilience requirement may require backup or recovery planning rather than another VM size.
Recovery objectives should distinguish backup from high availability. Availability zones reduce certain infrastructure failures, backups protect recoverable data states, and Site Recovery addresses disaster-recovery scenarios. These controls complement rather than replace one another.
The exam often rewards the service that matches the stated failure. If the requirement is to restore an accidentally deleted file inside a VM, that is different from keeping an application online when a zone fails.
Compare VMs with container hosting without mixing the models
The existing discussion of containers and hypervisors is useful when deciding why an application might use a VM rather than a container platform. A VM provides an operating-system boundary and broad control over the guest environment. Containers package applications with a lighter runtime model and are managed differently.
Architecture candidates may also encounter VM design choices in AZ-305, but AZ-104 remains operational. Know how to create, size, protect, move, monitor, and scale the VM resources that an architecture requires.
Practice by taking one workload and changing one requirement at a time: higher CPU, stronger availability, regional relocation, encrypted host processing, rapid horizontal scale, or stricter network access. Choose the VM operation or adjacent Azure control that directly satisfies the new requirement.
Choose size and scale from measurable workload needs
VM sizing should respond to evidence such as CPU pressure, memory consumption, disk throughput, or application concurrency. Oversizing wastes cost and can hide inefficient application behavior; undersizing creates performance incidents. Azure Monitor metrics and VM Insights can provide the observations needed to justify a resize or a move toward horizontal scaling.
A single larger VM and a scale set solve different problems. Vertical resizing increases resources for one instance, while a scale set supports a fleet that can expand or contract. If the application is stateful or tied to one host, horizontal scaling may require application changes before it becomes viable. The exam scenario may include this clue indirectly through requirements for elasticity or instance consistency.
When changing size, account for availability in the target region and any restart or operational impact. A correct technical choice still needs a workable maintenance plan.
Automate repeatable VM deployment with ARM or Bicep
The compute domain also measures ARM templates and Bicep, and VM administration is an obvious place to connect those objectives. A repeatable definition can capture the VM, network interface, disks, identity, extensions, and supporting resources so that environments can be rebuilt consistently. This is safer than relying on a long sequence of remembered portal choices.
Infrastructure as code also makes review easier. A size change, disk change, or network dependency is visible as a configuration difference that can be tested before deployment. Sensitive values should still be handled through secure mechanisms rather than embedded in the template.
For exam questions, do not choose automation simply because it sounds modern. Use ARM or Bicep when the requirement is repeatable deployment, modification of an existing template, or declarative resource creation. Use ordinary VM operations when the task is a one-off administrative change to an existing resource.
Distinguish availability from disaster recovery
Availability zones, availability sets, scale sets, backup, and Site Recovery can all appear in discussions about resilient virtual machines, but they protect against different events. Zones and sets improve availability across infrastructure failure domains. Backup preserves recoverable data states. Site Recovery supports disaster-recovery orchestration and failover to another location.
Read the recovery requirement precisely. “Keep the service available during a host failure” is different from “restore yesterday’s data” and different again from “fail over after a regional disaster.” Choosing the correct Azure control depends on that failure model.
A mature design may use several protections together. The exam, however, often asks for the specific service or configuration that satisfies one stated objective with the least unnecessary change.
Continue exploring the technologies and certification concepts that matter most to you.