Technical Lab: Deploy and configure an Azure Virtual Machine Scale Sets
Questions
Question 1 — Multiple Choice
An operations team needs to ensure that an Azure Virtual Machine Scale Set (VMSS) always maintains between 3 and 10 instances, with automatic scaling based on CPU. The engineer configures a scale-out rule when average CPU exceeds 75% for 5 minutes, and a scale-in rule when it falls below 30% for 10 minutes.
After one week, the team observes that the number of instances repeatedly oscillates between 4 and 5, even without actual load variation. Which autoscaling characteristic is the most likely cause of this behavior?
A) The metrics collection interval is configured with too high granularity, causing inaccurate readings.
B) The cooldown period is too short, allowing new scaling actions to occur before the system stabilizes after the previous adjustment.
C) The minimum instance value is preventing scale-in from reducing below 3, causing conflict with the scale-out rule.
D) The VMSS is using Uniform orchestration mode, which does not support custom scale-in rules.
Question 2 — Technical Scenario
An administrator deploys a VMSS with the following partial configuration:
"upgradePolicy": {
"mode": "Rolling",
"rollingUpgradePolicy": {
"maxBatchInstancePercent": 20,
"maxUnhealthyInstancePercent": 20,
"maxUnhealthyUpgradedInstancePercent": 5,
"pauseTimeBetweenBatches": "PT0S"
}
},
"automaticRepairsPolicy": {
"enabled": true,
"gracePeriod": "PT10M"
}
After updating the VMSS base image, 3 out of 10 instances become Unhealthy immediately after upgrading the first batch. The upgrade process stops completely.
What is the direct cause of the interruption?
A) The gracePeriod of 10 minutes blocked the health check of the first batch instances before the next could start.
B) The maxUnhealthyUpgradedInstancePercent value was exceeded, as 3 failed instances represent 30% of the total, above the 5% limit.
C) The pauseTimeBetweenBatches configured as PT0S does not allow enough time for instances to report health before the next batch.
D) Rolling mode requires the Application Health Extension to be installed; without it, all instances are marked as unhealthy by default.
Question 3 — True or False
In an Azure Virtual Machine Scale Set configured with Flexible orchestration mode, it is possible to manually add existing individual VMs to the scale set after its creation, in the same way you associate a VM to an Availability Set.
Question 4 — Technical Scenario
A critical application runs on a VMSS with 6 instances distributed across 3 fault domains and 5 update domains. The infrastructure team needs to apply an operating system update with minimal simultaneous impact, ensuring that instances in different fault domains are updated at different times.
The administrator considers the following approaches:
A) Configure upgradePolicy.mode as Automatic and adjust maxBatchInstancePercent to 20%, ensuring at most 1 instance is updated at a time.
B) Configure upgradePolicy.mode as Manual and execute Update-AzVmssInstance for each instance individually, controlling the order manually.
C) Configure upgradePolicy.mode as Rolling with maxBatchInstancePercent of 20% and enable the Application Health Extension to validate each batch before proceeding.
D) Migrate the VMSS to Uniform orchestration mode and use Scheduled Events to coordinate updates between fault domains.
Which approach best meets the requirement of minimizing simultaneous impact with automatic health validation between batches?
Question 5 — Multiple Choice
A VMSS uses Custom Script Extension to configure the application during provisioning. When scaling horizontally, new instances take much longer than expected to become ready. Analysis shows that each new instance downloads and executes an 800 MB script from an external internet endpoint.
Which change to the VMSS architecture would most directly eliminate this bottleneck?
A) Replace the Custom Script Extension with cloud-init, which executes scripts locally without external download dependency.
B) Reference the script from an Azure Storage Account with private endpoint in the same region as the VMSS, reducing download latency.
C) Incorporate the application configuration directly into the custom base image used by the VMSS, eliminating the need for script execution during provisioning.
D) Increase the VMSS instanceFlexibility so that new instances are provisioned with faster network SKUs during scale-out.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The "flapping" behavior (repeated oscillation between close values) is a classic consequence of an insufficient cooldown period. After a scaling action, the system needs time for new instances to start absorbing load and for metrics to stabilize. If the cooldown is too short, the autoscaler reads transient metrics from the adjustment period and triggers a new action in the opposite direction, creating a cycle.
The main error that distractors represent is confusing the problem with configuration limitations of minimum/maximum limits (C) or orchestration mode restrictions (D), when the problem is temporal, not structural. Alternative A is plausible but describes a data precision problem, not decision stability.
Choosing D would be particularly problematic: Uniform mode fully supports scale-in rules, and believing otherwise would lead the administrator to migrate the VMSS unnecessarily.
Answer Key — Question 2
Answer: B
The maxUnhealthyUpgradedInstancePercent parameter defines the maximum percentage of already updated instances that can be unhealthy for the process to continue. With 10 instances and maxBatchInstancePercent of 20%, the first batch contains 2 instances. However, the scenario indicates that 3 instances became unhealthy, representing 30% of the total updated up to that point, exceeding the 5% limit and stopping the rolling upgrade.
The most common conceptual error is confusing maxUnhealthyInstancePercent (limit over the entire scale set) with maxUnhealthyUpgradedInstancePercent (limit only over instances that have already gone through the upgrade). Alternative A is a sophisticated distractor: the Automatic Repairs gracePeriod is the time the system waits before repairing an unhealthy instance, and does not directly interfere with rolling upgrade progression. Alternative D would be true if the health extension were not installed, but the scenario does not indicate its absence.
Answer Key — Question 3
Answer: False
The VMSS Flexible mode allows individual VMs to be created and associated with the scale set at the time of VM creation, specifying the virtualMachineScaleSet as a reference. However, it is not possible to add existing independent VMs to a VMSS after its creation, unlike what occurs with Availability Sets, where a VM can be associated at different times in the lifecycle.
This distinction is critical: VMSS Flexible offers flexibility for individual instance management, but the association model is defined at VM provisioning time, not retroactively. Confusing the two models can lead to incorrect architectural decisions when planning migration of existing workloads to scale sets.
Answer Key — Question 4
Answer: C
Rolling mode with low maxBatchInstancePercent (20% = approximately 1 instance per batch in a set of 6) combined with the Application Health Extension is the approach that meets both requirements: minimizes simultaneous impact and automatically validates the health of each batch before proceeding to the next.
Alternative B (Manual) offers full control but does not guarantee automatic health validation between batches, requiring human intervention at each step, which increases operational risk. Alternative A (Automatic) with small batch reduces simultaneous impact, but Automatic mode does not pause for health validation between batches the same way Rolling does with health extension. Alternative D proposes an orchestration mode change that does not solve the central problem and adds unnecessary complexity.
Answer Key — Question 5
Answer: C
Incorporating configuration directly into the custom base image (via Packer, Azure Image Builder or similar) completely eliminates the need to download and execute scripts at provisioning time. This reduces instance startup time to VM boot time plus application startup time, without external dependencies.
Alternative B reduces latency but does not eliminate the bottleneck: 800 MB still needs to be downloaded and executed for each new instance. Alternative A is a relevant conceptual error: cloud-init can also depend on external scripts and does not execute "locally without download" by definition; the problem is the origin and size of the artifact, not the provisioning tool. Alternative D references instanceFlexibility, which is not a real VMSS parameter for controlling network SKU during scale-out.