How Do You Resize VM1 When the Target Azure VM Size Is Unavailable?

Create and configure virtual machines

Answer Correct answer: B — Deallocate VM1 first so Azure can move it to a host cluster that offers the 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?

Create a proximity placement group.
Deallocate VM1. Correct Answer
Convert AvSet1 into a managed availability set.
Shut down VM3 and VM3.

Community Votes

100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the distinction between stopping and deallocating an Azure VM, and the trap is choosing a resiliency or placement feature (availability set, proximity placement group) when the real constraint is the host cluster's available SKU inventory.

When VM1 in availability set AVSet1 cannot be scaled to the intended Azure VM size, the size is usually missing from the current host cluster. The page establishes that deallocating VM1 first is the required step, because only a deallocated VM releases the hardware allocation needed for Azure to place it on a cluster that offers the new size.

The most common wrong answer is simply shutting down or stopping VM1 without deallocating it; a stopped (but not deallocated) VM keeps its host allocation, so Azure may still not offer the missing size.

Community Discussion (3 comments)

Elite4Life 👍 14 Selected: B

B - When you need to scale up a virtual machine (VM1) to a new size, and the intended size is unavailable, the most likely reason is that the size is not available on the current hardware cluster where the VM is hosted. To make the new size available, you must move the VM to a different cluster, which requires deallocating the VM.

vrm1358 👍 1 Selected: B

This might be the direct answer on MS website: "If your VM is still running and you don't see the size you want in the list, stopping the virtual machine may reveal more sizes." ref: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm?tabs=portal

CubicTeach 👍 3

answer given is right, Deallocating the VM will release the current hardware resources, making it possible to move the VM to a different hardware cluster that supports the new size. Here are the steps: Deallocate VM1: This stops the VM and releases the associated resources. Resize VM1: After deallocation, you can attempt to resize VM1 to the new desired size. Start VM1: Once resized, you can start the VM again.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Deallocating VM1 (option B) is correct because Azure can only offer VM sizes that exist on the host cluster currently backing the VM. When the desired size does not appear in the resize list, the VM generally needs to move to different hardware, and deallocation (Stopped (deallocated)) releases the compute and host resources so Azure can re-place VM1 on a cluster that stocks the target SKU. The normal flow is deallocate VM1, resize it while deallocated, and then start it again. The community comments agree with this mechanism: as Elite4Life explained, the size is likely unavailable on the current hardware cluster, and moving the VM requires deallocating it. CubicTeach likewise described the deallocate, resize, start sequence as the way to release current resources and reach a cluster that supports the new size.

Why the Other Options Are Wrong

A proximity placement group (A) influences placement latency relative to other resources, but it does not create or unlock an unavailable VM SKU on the current cluster. Converting AVSet1 into a managed availability set (C) is not a supported first step for a size problem, and availability set configuration does not change which hardware SKUs a cluster can offer for resizing. Shutting down VM3 (D) is irrelevant to VM1's host allocation, and the option as written is also malformed with the repeated "VM3" wording. None of these options releases VM1's current hardware allocation, which is the actual obstacle to seeing the intended size.

Community Comment Notes

Elite4Life's highly liked answer frames the problem as a hardware cluster limitation and concludes that moving the VM to a different cluster requires deallocating VM1. CubicTeach adds the practical sequence of deallocating VM1, attempting the resize, and then starting VM1 again once the new size is accepted. vrm1358 points to Microsoft guidance with the verbatim phrase "stopping the virtual machine may reveal more sizes", which matches the exam's expectation that a full deallocation, not just an OS shutdown, is what exposes additional SKUs.

Official Reference

https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm?tabs=portal

Exam Strategy

For AZ-104 resize questions, always check whether the VM is merely stopped or actually deallocated; an unavailable size almost always means the current host cluster lacks that SKU, so releasing the allocation comes before choosing a resiliency feature.

Frequently Asked Questions

Why must VM1 be deallocated before resizing to an unavailable size?

The current host cluster may not stock that SKU; deallocation releases VM1's hardware so Azure can place it on a cluster that offers the size.

Does converting AVSet1 into a managed availability set fix the missing VM size?

No. Availability set configuration affects resiliency and management, not the host cluster's SKU inventory, so it cannot make the intended size appear.

Related Analysis

Practice All AZ-104 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-104 Practice Test →

← Back to AZ-104 Study Guide