AZ-104
Deep Dive
VMSS lets you deploy and manage sets of identical VMs that scale automatically. The AZ-104 tests scaling modes, autoscale rules, update policies, and the Flexible vs Uniform model.
Contents
A Virtual Machine Scale Set is a resource that creates and manages a group of identical VMs (same image, same size). It lets you scale the number of instances manually or automatically based on demand, with built-in load balancing.
VMSS is the foundation of AKS node pools, App Service, and many Azure services internally. For the AZ-104, the focus is on creating and managing VMSS directly.
When to use VMSS
When to use individual VMs
VMSS limits
Manual Scaling
You define a fixed number of instances. You change the number manually when you need more or less capacity.
Pros
Simple, predictable, no cost surprises.
Cons
Requires manual intervention. Can waste resources or fall short during spikes.
Autoscale (metric)
Rules that increase or decrease instances based on metrics (CPU, memory, Custom Metrics, Service Bus queue length, etc.).
Pros
Reactive to real demand. Optimizes cost automatically.
Cons
Lag between the trigger and active instances. More complex configuration.
Schedule-based
Configures the number of instances based on days/hours. E.g.: 10 instances from 8am to 8pm (business hours), 2 instances the rest of the time.
Pros
For very predictable loads. No warmup lag.
Cons
Does not react to unexpected demand outside the schedule.
Anatomy of an autoscale rule
Metric source
Where the metric comes from: the VMSS itself, a Storage Account, Service Bus, Application Insights. Most common: VMSS % CPU.
Condition
Metric, operator (>, <, >=, <=, ==), threshold, and time window. E.g.: "average CPU > 70% over the last 10 minutes".
Action
What to do if the condition is met: increase/decrease the count by N instances, or set an absolute count. With a cooldown period.
Cooldown
Wait time after a scaling event before evaluating again. Prevents thrashing (scaling out and in continuously). Default 5 min.
Example: scale out + scale in rules
Scale Out (add instances)
When average CPU > 70% over the last 10 min
→ Increase by 2 instances | Cooldown: 5 min
Scale In (remove instances)
When average CPU < 30% over the last 15 min
→ Decrease by 1 instance | Cooldown: 10 min
Limits always apply
Minimum: 2 instances | Maximum: 20 instances
Autoscale best practices
When you change the image or configuration of the VMSS, the update policy defines how and when the change propagates to existing instances.
Automatic
Azure automatically updates all instances as soon as possible, in batches. No manual intervention.
Can cause downtime if the app does not tolerate mixed instances during the rollout.
Rolling
Updates in batches (configurable % of the total). Waits for the previous batch to be healthy before continuing. Accepts pause configuration.
Safer. Can be combined with health probes to validate each batch.
Manual
New instances use the new image. Existing ones are NOT updated automatically — you must update each instance manually (upgrade instance).
Maximum control. Instances on different versions until you update them.
How it works
If a VMSS instance becomes unhealthy (a health probe fails or the app inside the VM reports unhealthy), Azure automatically removes it and creates a new instance in its place.
• Requires configuring an Application Health Extension or a Load Balancer health probe
• Grace period: time it waits before repairing (default 30 min) — so the app has time to start up
• The faulty instance is removed and a new one is created from the base image
• Combined with the Rolling update policy: deploy + automatic self-healing
Application Health Extension
An extension installed on each VMSS instance. Sends an HTTP request to the app's health endpoint (e.g.: /health) and reports the status to the VMSS.
• You configure: protocol (HTTP/HTTPS/TCP), port, and path of the health endpoint
• The app responds 200 OK = Healthy. Any other code or timeout = Unhealthy
• Also lets Rolling Updates wait for the batch to be healthy before continuing
| Dimension | Uniform (classic) | Flexible (recommended) |
|---|---|---|
| Instance identity | Numeric Instance ID (0, 1, 2...) | Full Azure VM ID — each instance is a real VM |
| Management APIs | VMSS-specific APIs | Same APIs as individual VMs + VMSS |
| Spot mixing | All Spot or all regular | Mix Spot + regular in the same VMSS |
| VM sizes mixing | A single size | Multiple sizes in the same VMSS |
| Availability Zones | Supported | Supported + better distribution (zone balancing) |
| Service integration | Limited to VMSS APIs | Full — appear as normal VMs in the portal |
| Recommended for | AKS node pools internally, legacy scenarios | New workloads, replaces Availability Sets |
Microsoft's recommendation
For new deployments: use VMSS Flexible. It replaces both classic Uniform VMSS and Availability Sets (which no longer receive new features). Flexible mode gives the scaling advantages of VMSS with the flexibility of individual VMs.
To use VMSS efficiently you need consistent base images. Azure Compute Gallery (formerly Shared Image Gallery) organizes and distributes custom images.
Hierarchy in Azure Compute Gallery
Gallery
Container for image definitions. Can be shared across subscriptions and tenants.
Image Definition
Image metadata: OS, publisher, offer, SKU, architecture, lifecycle state.
Image Version
The actual version (1.0.0, 2.0.0...). Automatically replicates to multiple regions. Has an optional expiration date.
Generalized vs Specialized
Generalized
The VM was sysprepped (Windows) or deprovisioned (Linux) before capture. Removes host-specific data. Each new VM gets a new name, SID, hostname.
Specialized
Exact capture of the original VM's state: same hostname, SID, local accounts. For DR or exact cloning.
Azure Image Builder
A managed service for automatically building custom images: starts from a base image (Marketplace or custom), applies configuration scripts, and publishes the image to Azure Compute Gallery. Integrates with CI/CD.
Did you get this topic?
Test what you just learned
A VMSS is configured with Autoscale: scale out when CPU > 75% for 10 minutes, and scale in when CPU < 25% for 5 minutes. The scale-out cooldown is 3 minutes and the scale-in cooldown is 5 minutes. CPU rises to 80% and 2 instances are added. Two minutes later CPU drops to 20%. What happens?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.