Which Azure VM grouping for the two 100-VM deployments?
HOTSPOT
You have an Azure subscription.
You plan to deploy two 100-virtual machine deployments as shown in the following table.
You need to recommend a virtual machine grouping solution for the deployments.
What should you include in the recommendation for each deployment? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.

Community Insight
The exam tests whether you can map a workload's placement keywords to a scale-set orchestration mode — the trap is assuming availability sets or one single mode handles both zone-spanning VMs and PPG/update-domain requirements.
This AZ-305 hotspot asks you to pick the correct Azure VM grouping for two separate 100-virtual-machine deployments, where the requirement keywords are availability zones for one and a proximity placement group with update domains for the other. The page establishes that Deployment 1 takes a virtual machine scale set in flexible orchestration mode and Deployment 2 takes one in uniform orchestration mode.
Most candidates reach for an availability set or a proximity placement group on its own and forget that an availability set cannot span availability zones, so neither deployment's stated requirements are actually satisfied by that grouping.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The two rows of the exhibit are distinguished by their design keywords: Deployment 1 calls out availability zones, and Deployment 2 calls out a proximity placement group together with support for update domains. A virtual machine scale set in flexible orchestration mode treats each of the 100 instances as a standard Azure VM while still letting the set span availability zones, which is exactly the zone-resilient grouping Deployment 1 needs. Deployment 2 instead requires low-latency co-location (a proximity placement group) and staged patching across update domains, and both of those are characteristics of uniform orchestration mode rather than flexible. Scale is not the deciding factor here — both modes comfortably host 100 instances (flexible supports up to 1,000) — so the requirement keywords alone select the mode.Why Other Candidate Answers Are Wrong
An availability set is the classic wrong pick: it distributes VMs across fault and update domains but is scoped to a single zone, so it can never satisfy Deployment 1's availability-zone requirement. Choosing uniform orchestration mode for both deployments is equally wrong, because the flexible mode's per-VM management model and zone spanning are what the first row asks for, and uniform's update-domain semantics only match the second row. Selecting a bare proximity placement group (without a scale set) is a partial answer — it addresses latency for Deployment 2 but ignores the update-domain requirement and gives no grouping mechanism for Deployment 1. Putting flexible orchestration on Deployment 2 also fails, since the PPG plus update-domain combination is the uniform-mode profile.Community Comment Notes
mesloth condenses the scenario into two keyword pairs, quoting "Key word: proximity placement group and support for update domains" for the second deployment and noting availability zones as the keyword for the first, then mapping Deployment 1 to "VMSS Flexible" and Deployment 2 to "VMSS Uniform". That keyword-matching approach is the right mental model for this hotspot item, because the table deliberately omits any other distinguishing detail. No commenter in the thread argues for an availability set or a standalone proximity placement group, so the community reading and the documented orchestration-mode capabilities agree on the same two selections.Official Reference
Exam Strategy
Read the exhibit table for the one or two design keywords per row (availability zones, proximity placement group, update domains, fault domains) before comparing products. Availability sets are almost always the distractor in AZ-305 compute-grouping items because they cannot span zones.
Frequently Asked Questions
Why can't an availability set be used for the deployment that requires availability zones?
An availability set scopes its fault and update domains to a single zone, so its VMs can never be spread across availability zones. Only a zone-aware grouping such as a scale set in flexible orchestration mode meets that requirement.
Why does the deployment needing a proximity placement group and update domains use uniform orchestration?
Uniform orchestration mode keeps update-domain semantics and supports co-locating instances in a proximity placement group for low latency. Flexible mode manages instances as individual VMs and is the better fit for zone-spanning, not for that PPG plus update-domain profile.
Related Analysis
Practice All AZ-305 Questions
Access 95 questions with complete answers and detailed explanations.
View Full AZ-305 Practice Test →