First Step to Resize an Azure VM to an Unavailable Size
You have an Azure subscription that contains three virtual machines named VM1, VM2, and VM3. All the virtual machines are in an availability set named AVSet1. You need to scale up VM1 to a new virtual machine size, but the intended size is unavailable. What should you do first?
Community Insight
The question tests whether you know a running VM can only see sizes available on its current hardware cluster; the trap is choosing to shut down the other VMs in the availability set instead of deallocating VM1 itself first.
In AZ-104's VM resize scenario, the target size is missing because a running VM is pinned to the hardware cluster hosting it, and the size list only shows sizes supported by that cluster. The page establishes that the correct first action is to deallocate VM1, which releases its hardware slot and exposes additional sizes before you resize.
Option D (shut down the other VMs in AVSet1) is the common wrong pick: learners assume the entire availability set must be relocated first, but the question asks for the FIRST action, and Microsoft's guidance is to stop/deallocate the VM being resized to reveal more sizes.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Deallocating VM1 (B) is the documented first step, because a running VM can only be sized within the capacity of the hardware cluster it currently occupies, so the size picker hides any size that cluster cannot host. Microsoft's resize guidance states that if the VM is still running and the desired size is not listed, stopping (deallocating) the virtual machine may reveal more sizes — deallocation releases the underlying hardware resources and lets Azure re-place the VM on a cluster that supports the intended size. The workflow is therefore deallocate VM1, then resize VM1 to the new size, then start VM1 again. Since the question asks what to do FIRST, the deallocation of VM1 is the answer regardless of any later steps involving the rest of the availability set.Why the Other Options Are Wrong
A proximity placement group controls physical latency-based colocation of Azure compute resources and does nothing to increase size availability, so it cannot make an unsupported size appear. C converting AvSet1 to a managed availability set is a legacy migration for unmanaged availability sets and frees no hardware capacity; every availability set created in the portal today is already managed, so the step is a no-op for capacity purposes. D is malformed in the option text ("Shut down VM3 and VM3") and is also wrong on sequence: shutting down VM2 and VM3 does not help while VM1 itself is still running and pinned to its cluster, and you must deallocate VM1 before any resize is even possible. Even if a whole-set cluster move were eventually required, it would come after, not before, deallocating VM1.Community Comment Notes
Elite4Life's top-voted explanation matches the vendor guidance, noting "you must move the VM to a different cluster, which requires deallocating the VM." vrm1358 reinforces this by quoting the official article directly: "stopping the virtual machine may reveal more sizes," linking the resize-vm documentation. FemiA55 and 121b15e argue the answer should be shutting down every VM in the availability set so Azure can re-place the set on a supporting cluster — a plausible later condition, but it skips the prerequisite first step and relies on an option whose wording is corrupted. CubicTeach's step sequence (deallocate VM1, resize, start) agrees with the chosen answer.Official Reference
Exam Strategy
On AZ-104 resize questions, watch the word "first": always identify the action that unblocks the operation on the specific VM named (deallocate it) rather than a broader, later remediation. Remember that a running VM only lists sizes supported by its current hardware cluster, so stopping it is the gate to seeing more options.
Frequently Asked Questions
Why can't I resize Azure VM1 while it is still running?
A running VM is pinned to the hardware cluster it lives on, and the size list only shows sizes that cluster supports. Deallocating the VM releases the slot and reveals more sizes.
Do I need to shut down all VMs in AVSet1 to resize VM1?
Not as the first step. Deallocate VM1, resize it, then start it; only if the new size is unsupported on the set's cluster would the whole availability set need to move.
Related Analysis
Practice All AZ-104 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-104 Practice Test →