4 of the 13 questions we have for this objective, shown with the answer and the reasoning.
Create and configure virtual machines
Dunmore Robotics runs a simulation farm and wants a single Virtual Machine Scale Set in the East US region. The set must contain a baseline of four regular Standard_F16s_v2 instances plus a variable number of Azure Spot instances of the same size that can be evicted, and the team also wants to attach two existing, manually built license-server VMs to the same set so that all of the farm's VMs are managed as one group. The team is creating the scale set now.
Which orchestration mode should you choose?
- AFlexible orchestrationFlexible orchestration supports mixing Spot and regular priority instances in one set, allows heterogeneous VMs, and lets you add existing standalone VMs to the scale set.
- BUniform orchestrationUniform orchestration manages identical instances from a single model, uses a single priority setting for the whole set, and does not allow manually created VMs to join the set.
- CUniform orchestration with a second scale set for the Spot instancesTwo scale sets could separate Spot from regular capacity, but the scenario requires a single set and still cannot include the existing license-server VMs.
- DAn availability set with a proximity placement groupAn availability set offers fault domain spreading but no autoscaling, no Spot mixing, and cannot have existing VMs added after their creation.
Why: The orchestration mode is set at creation and cannot be changed, so the exam tests whether you know which capabilities require which mode. Uniform orchestration treats instances as identical copies of one model, which is ideal for stateless, rapidly scaling workloads. Flexible orchestration treats the set as a container of individual VMs: it supports mixing Spot and standard priority with a configurable Spot mix, different sizes, and attaching existing VMs (which requires the set to use max spreading, platformFaultDomainCount = 1, with singlePlacementGroup set to false), while still spreading across fault domains and zones. Every requirement in this scenario points to Flexible.
Create and configure virtual machines
Silverpine Media must relocate twelve virtual machines, their managed disks, network interfaces, a virtual network and a network security group from the West US region to the West US 3 region because of a data-residency commitment. The company wants a guided, single-pane process that validates dependencies, performs the move and allows a test before committing, with minimal custom scripting.
What should you use?
- AAzure Resource MoverResource Mover is built for cross-region moves. It discovers dependencies, prepares and initiates the move of VMs, disks, NICs, virtual networks and NSGs, and lets you discard or commit the move.
- BThe Move to another region option on each resource groupThe resource group move operation changes only the resource group or subscription; it has no region option because the region is a property of the resources themselves.
- CAzure Backup with a cross-region restore of each VMCross-region restore only targets the paired region of a geo-redundant vault and restores VMs one at a time without moving the networking; it is a disaster recovery feature, not a planned-move tool.
- DAzure Site Recovery with a failover to West US 3 for each VMSite Recovery can be used to move VMs between regions, but it requires per-VM replication and failover with manual recreation of the virtual network and NSG; Resource Mover provides the guided, dependency-aware experience the scenario asks for.
Why: A region move is fundamentally a copy-and-recreate, because an Azure resource's region cannot be changed in place. Azure Resource Mover wraps that process: it validates dependencies, prepares the target resources, initiates the move, and provides a commit or discard step so you can test before deleting the source. Site Recovery is the underlying technology for VMs and remains an option, but it is per-VM and does not move supporting resources like virtual networks and NSGs. The resource group move operation never changes regions.
Create and configure virtual machines
Copperfield Bank is deploying two identical web virtual machines, vm-web01 and vm-web02, behind a load balancer in the Central US region, which supports availability zones. The bank's contract requires the highest VM connectivity SLA that Azure offers for the pair.
How should you deploy the virtual machines?
- APlace both VMs in the same availability set with two fault domains.An availability set protects against rack and host failures within one datacenter and provides a 99.95% SLA, which is lower than the zonal SLA.
- BDeploy vm-web01 in availability zone 1 and vm-web02 in availability zone 2.Two or more VMs deployed across two or more availability zones in the same region receive the 99.99% VM connectivity SLA, the highest available.
- CDeploy both VMs in availability zone 1 with Premium SSD disks.Two VMs in the same zone share that zone's failure domain. A single-instance VM with Premium SSD or Ultra disks gets 99.9%, not 99.99%.
- DDeploy both VMs in a proximity placement group.A proximity placement group reduces network latency by co-locating VMs; it does not increase availability and concentrates both VMs in the same failure domain.
Why: The SLA ladder for Azure VMs is: 99.9% for a single VM whose disks are all Premium SSD or Ultra, 99.95% for two or more VMs in an availability set, and 99.99% for two or more VMs spread across two or more availability zones in the same region. Availability zones are physically separate datacenters with independent power, cooling and networking, which is what justifies the higher figure. When a region supports zones and the deciding constraint is the highest SLA, zones win over sets.
Create and configure virtual machines
Greywell Manufacturing runs a legacy application on a single virtual machine named vm-mes01 in the South Central US region. The application vendor supports only active-passive deployment, so the company creates a second VM named vm-mes02 and wants both VMs placed in a new availability set named avset-mes so that planned maintenance and hardware failures do not take both down at once. The administrator creates avset-mes, then tries to add vm-mes01 to it from the VM's Availability + scaling blade and cannot.
What should you do?
- ADelete vm-mes01 while keeping its disks, recreate it from the existing OS disk with avset-mes selected, and create vm-mes02 in avset-mes.Availability set membership is chosen when a VM is created and cannot be changed afterwards. Recreating the VM from its existing OS disk preserves data while allowing the set to be specified.
- BStop (deallocate) vm-mes01 and then select avset-mes on the Availability + scaling blade.Deallocation enables resizing and disk changes but does not unlock availability set assignment, which is immutable after creation.
- CCreate vm-mes02 in avset-mes and move vm-mes01 into the resource group that contains avset-mes.Resource group placement is unrelated to availability set membership; the VM would still not be part of the set.
- DCreate avset-mes with a single fault domain so that existing VMs can join it.The number of fault domains governs how VMs in the set are spread across racks; it does not permit adding an existing VM to the set.
Why: An availability set is a logical grouping that must be assigned at VM creation time. Azure then spreads the VMs across fault domains (racks with separate power and switch) and update domains (groups rebooted together during planned maintenance), which gives the 99.95% SLA. Because membership is immutable, bringing an existing VM into a set means recreating it, which is why the recommended practice is to decide on sets or zones when designing the deployment. Keeping the OS disk and rebuilding the VM is the least disruptive path.