Topics

Show in graph
ComputeNot studiedBlocked by 2

Virtual Machine Scale Sets

Horizontally elastically scaling identical VMs, with orchestration modes, upgrade policies and instance protection.

Readiness

0%

Importance

1h 50m baseline

Exam memorization points

  • Uniform orchestration manages identical VM instances from a single model; Flexible orchestration lets you mix configurations and is the newer recommendation.
  • Autoscale rules are metric based (for example average CPU above 70%) or schedule based, with a scale-out and scale-in profile and cooldown periods.
  • Upgrade policies: Automatic, Rolling (with batch size and pause), and Manual. Manual requires an explicit OS upgrade per instance.
  • Instance protection has two independent flags: protect from scale-in, and protect from scale set actions.
  • Overprovisioning creates extra instances during deployment to reduce provisioning time, then removes the surplus.
  • Default scale-in behaviour even-spreads across zones first, then removes the instance with the highest instance ID.

Traps & distractors

  • Scaling in and losing state. Scale-in deletes instances, so all state must live outside the instance.
  • Leaving the upgrade policy on Manual and then wondering why the new image never lands on the instances.
  • Assuming a change to the VM model applies immediately. Model changes create a new model and require an upgrade.
  • Forgetting that a load balancer or Application Gateway is what distributes traffic to the instances - the scale set itself does not.

Suggested lab

Autoscale a scale set under load

1hcost medium

Observe scale-out, scale-in and instance protection behaviour.

  1. 1Create a Uniform scale set with 2 instances behind a Standard Load Balancer.
  2. 2Add an autoscale rule to scale out at average CPU above 70% and scale in below 30%, with a 5-minute cooldown.
  3. 3Generate CPU load on the instances and watch the instance count climb.
  4. 4Enable protect-from-scale-in on one instance and force a scale-in operation.
  5. 5Switch the upgrade policy to Manual, change the image version and confirm instances stay unchanged until upgraded.

Microsoft Learn

Live Microsoft Learn ingestion is a Sprint 2 item; until then links are curated and the search fallback always resolves.

Status

No time invested yet. Baseline assumptions only.

Self-assessed mastery

0%

0%50%100%
Computed readiness0%
Logged study time0 min
Last studiednever
Last updatedtoday
74/ 100

High priority

Strong exam value. Schedule this week.

  • Exam importance80% × 30% = 24.0

    Learner-agnostic frequency on the real exam (4/5).

  • Blueprint weight100% × 25% = 25.0

    This topic's domain carries 22.5% of the exam objectives.

  • Dependency leverage0% × 20% = 0.0

    Nothing else in the graph depends on this topic.

  • Current gap100% × 25% = 25.0

    Readiness is 0%, so 100% of the topic is still uncovered.

Exam Priority Score = 30% importance + 25% blueprint + 20% dependency + 25% gap. Importance is exam frequency, blueprint is the domain's official exam weight, dependency is how many later topics this one unlocks, and gap is how far you currently are from ready.

Prerequisites

Locked until prerequisites reach 50% readiness.

Unlocks next

Leaf topic - nothing depends on it.

Baseline study time

1h 50m

Complexity

3 / 5

Remaining to target

1h 34m

Status weight

0%

Topics: vmss, autoscale, orchestration, upgrade policy, instance protection, overprovisioning

Weak neighbours in Compute