A city architect must explain when to choose Virtual Machine Scale Sets versus an availability set. Which describe-level contrast is accurate?
Select an answer to reveal the explanation.
Short Explanation
Scale sets are about growing a matching pack of VMs. Availability sets are about spreading VMs so one hiccup does not take the whole group. Different jobs — do not swap the nameplates.
Full Explanation
Virtual Machine Scale Sets and availability sets solve different problems at describe depth. Scale sets focus on managing and scaling sets of identical VMs—growing and shrinking capacity for workloads like identical web tiers. Availability sets focus on availability grouping: placing VMs across fault and update domains so maintenance or a hardware fault is less likely to take the whole group down together. A city architect should keep those jobs distinct when explaining when to choose each feature.
Saying availability sets only add identical autoscale capacity while scale sets only define fault domains and never scale swaps the feature purposes. Saying both features are only storage redundancy modes and never apply to virtual machines misclassifies them as storage settings. Saying scale sets replace Microsoft Entra ID while availability sets replace Azure DNS invents identity and DNS substitutions that neither feature performs.
Exam caveat: modern designs sometimes combine scale sets with availability concepts or zone deployment options; Fundamentals still expects the core contrast—scale versus fault/update-domain availability grouping—without requiring deep version-specific deployment mode trivia. Operational check: for a portal that needs both capacity elasticity and in-datacenter spreading, document whether you need scale-set autoscale, availability-set domain spreading, zone deployment, or a documented combination—and verify the chosen construct in the portal properties before production cutover.