AZ-104 Deploy and Manage Azure Compute Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  A proximity placement group for the scale set instances.

  Why it's wrong here

  A proximity placement group does not change instance count; it physically groups VMSS instances to minimize network latency between them. While it can improve performance for tightly coupled workloads, it tightly constrains scaling because all instances must be placed within the same group, and demand spikes cannot trigger adding instances. The described CPU pattern requires dynamic horizontal scaling, which proximity placement groups, as a placement construct, do not provide.

  When this WOULD be correct

  When the question requires minimizing network latency between VMs in a scale set for a latency-sensitive distributed application, such as a high-performance computing (HPC) workload, a proximity placement group would be the correct choice.

• ✗

  Manual scale operations only.

  Why it's wrong here

  Manual scale operations require an operator to change the VMSS capacity, such as through the Azure portal, CLI, or PowerShell. Unlike autoscale, there is no rule that reacts to CPU thresholds, so the described changing CPU pattern would go unaddressed until a human intervenes. Manual scaling also lacks the scheduling and notification features of autoscale, making it unsuitable for automatically adapting to workload peaks.

  When this WOULD be correct

  If the question specified that the workload is unpredictable and requires human judgment to avoid scaling thrashing, or if the organization has a policy requiring manual approval for all scaling changes, then manual scale operations would be the correct answer.

• ✓

  Autoscale rules on the virtual machine scale set.

  Why this is correct

  Autoscale rules on the virtual machine scale set correctly solve this. Azure VMSS can scale out and in automatically based on a metric such as average CPU percentage, with thresholds and duration windows. The autoscale engine reacts to the changing CPU pattern by adding or removing instances, and because the app is stateless, new instances can serve traffic immediately. This is the only option that provides the required automatic, metric-driven scaling.

• ✗

  An availability set with three update domains.

  Why it's wrong here

  An availability set with three update domains is a high-availability construct for standalone VMs, not an instance-count scaling mechanism. It distributes VMs across different update and fault domains so maintenance events don't take down all VMs, but the VMSS uses its own fault-domain and instance-distribution settings. Moreover, update domains only affect maintenance sequencing; they do not add or remove instances based on CPU load.

  When this WOULD be correct

  A question asks: 'You need to deploy two VMs running a line-of-business application that must remain available during Azure platform updates. What should you configure?' In that case, an availability set with multiple update domains ensures that not all VMs are updated simultaneously.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question