AZ-305 Design infrastructure solutions 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.

• ✓

  Virtual Machine Scale Sets configured with autoscale rules based on CPU and distributed across availability zones

  Why this is correct

  Virtual Machine Scale Sets are the only compute option listed that runs your workload on IaaS VMs while natively supporting horizontal autoscale: you define a scale condition (e.g., scale out by one instance when CPU percentage exceeds 75%, scale in when below 25%) and Azure applies it to the entire set. Deploying the VMSS across multiple availability zones places instance replicas in physically separate datacenters within the region, so a zone outage does not take down the entire web tier. This combination directly satisfies both the CPU-based automatic scaling and the zone-failure protection requirement.

• ✗

  Azure App Service with autoscale rules and deployment slots

  Why it's wrong here

  Azure App Service is a platform-as-a-service offering that abstracts and manages the underlying VMs on your behalf; even though it supports autoscale rules and deployment slots, you are never selecting or patching the virtual machines yourself, which violates the explicit "on Azure virtual machines" constraint in the requirement. The autoscaling in App Service scales the number of worker instances running on a shared or dedicated App Service plan, not VM scale sets, and deployment slots address staging and swap rather than compute capacity. Because the prerequisites demand IaaS-level VM control, App Service is disqualified despite its operational convenience.

• ✗

  Azure Load Balancer with a backend pool of VMs and autoscale rules applied to individual VMSS

  Why it's wrong here

  An Azure Load Balancer is a Layer-4 load balancer that distributes traffic to a backend pool, but it has no autoscale engine of its own; any scaling rules must be created on the VMSS (or a separate autoscale setting), so this option merely describes an architectural fragment rather than a complete solution. If the backend pool is simply a loose list of standalone VMs, you cannot apply CPU-based autoscale to them at all, because autoscale in Azure is attached to a scale set. Even with a VMSS behind the load balancer, the option does not state that the scale set is distributed across availability zones, so it fails part of the high-availability requirement.

• ✗

  Azure Traffic Manager with endpoints in separate regions and Manual scaling of VMs

  Why it's wrong here

  Azure Traffic Manager is a DNS-based global traffic router used to steer users to endpoints in different Azure regions; it does not monitor CPU utilization of your VMs and cannot automatically add or remove VM instances based on load. The requirement is for automatic scaling based on CPU and protection against a zone failure within a region, and manually scaling VMs directly contradicts "automatic". Spreading endpoints across regions can protect against a regional outage if you replicate the app, but that is not the same as zone-level high availability, and the lack of autoscale makes this option invalid.

Go deeper

Related to this question