VM Scale Sets for auto scaling in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Azure VM Scale Sets handle instance health during auto scaling?

When Azure VM Scale Sets automatically scale out or in, how does it manage the health of individual VM instances?

A It requires manual intervention to remove unhealthy instances before scaling.

B It automatically replaces unhealthy instances with new ones to maintain the desired capacity.

C It ignores instance health and only scales based on CPU usage thresholds.

D It pauses scaling operations until all instances report healthy status manually.

💡 Hint

Think about how auto scaling ensures service availability without manual steps.

Azure VM Scale Sets monitor instance health and automatically replace unhealthy VMs to keep the set at the desired capacity, ensuring continuous availability.

❓ Configuration

intermediate

Which JSON snippet correctly configures a VM Scale Set with automatic scaling based on CPU usage?

Identify the correct JSON snippet to configure an Azure VM Scale Set to scale out when average CPU usage exceeds 70% and scale in when below 30%.

A { "autoscaleSettings": { "profiles": [{ "name": "AutoScaleProfile", "capacity": { "minimum": "2", "maximum": "10", "default": "5" }, "rules": [{ "metricTrigger": { "metricName": "CPU Usage", "threshold": 80, "operator": "GreaterThan", "timeAggregation": "Average", "timeWindow": "PT10M" }, "scaleAction": { "direction": "Increase", "type": "PercentChange", "value": "10", "cooldown": "PT10M" } }] }] } }

B { "autoscaleSettings": { "profiles": [{ "name": "AutoScaleProfile", "capacity": { "minimum": "1", "maximum": "5", "default": "2" }, "rules": [{ "metricTrigger": { "metricName": "Percentage CPU", "threshold": 70, "operator": "LessThan", "timeAggregation": "Average", "timeWindow": "PT5M" }, "scaleAction": { "direction": "Increase", "type": "ChangeCount", "value": "1", "cooldown": "PT5M" } }] }] } }

C { "autoscaleSettings": { "profiles": [{ "name": "AutoScaleProfile", "capacity": { "minimum": "1", "maximum": "3", "default": "1" }, "rules": [{ "metricTrigger": { "metricName": "Percentage CPU", "threshold": 50, "operator": "GreaterThan", "timeAggregation": "Average", "timeWindow": "PT1M" }, "scaleAction": { "direction": "Increase", "type": "ChangeCount", "value": "2", "cooldown": "PT2M" } }] }] } }

D { "autoscaleSettings": { "profiles": [{ "name": "AutoScaleProfile", "capacity": { "minimum": "1", "maximum": "5", "default": "2" }, "rules": [{ "metricTrigger": { "metricName": "Percentage CPU", "threshold": 70, "operator": "GreaterThan", "timeAggregation": "Average", "timeWindow": "PT5M" }, "scaleAction": { "direction": "Increase", "type": "ChangeCount", "value": "1", "cooldown": "PT5M" } }, { "metricTrigger": { "metricName": "Percentage CPU", "threshold": 30, "operator": "LessThan", "timeAggregation": "Average", "timeWindow": "PT5M" }, "scaleAction": { "direction": "Decrease", "type": "ChangeCount", "value": "1", "cooldown": "PT5M" } }] }] } }

💡 Hint

Look for correct metric names, thresholds, and scale directions for both scale out and scale in.

Option D correctly sets scale out when CPU > 70% and scale in when CPU < 30%, with proper metric names and scale actions.

❓ Architecture

advanced

What is the best architecture to ensure zero downtime during VM Scale Set upgrades?

You want to upgrade your VM Scale Set instances without any downtime. Which architecture approach achieves this?

A Manually stop all VMs, update the image, then start them again at once.

B Delete all instances and recreate them with the new image simultaneously.

C Use rolling upgrades with health probes and automatic instance replacement to update VMs gradually.

D Disable auto scaling during upgrade and update instances one by one without health checks.

💡 Hint

Think about how to keep some instances running while others update.

Rolling upgrades update instances in batches, using health probes to ensure only healthy VMs serve traffic, preventing downtime.

❓ security

advanced

Which practice secures VM Scale Sets against unauthorized SSH access?

To protect your VM Scale Set instances from unauthorized SSH access, which practice is most effective?

A Use Azure Network Security Groups to restrict SSH access to specific IP addresses only.

B Open SSH port 22 to all IP addresses for easy access from anywhere.

C Disable SSH and rely only on RDP for all instances.

D Use default usernames and passwords for quick setup.

💡 Hint

Consider how to limit who can connect via SSH.

Network Security Groups can restrict SSH access to trusted IP ranges, reducing attack surface and improving security.

✅ Best Practice

expert

What is the recommended approach to manage stateful applications on VM Scale Sets?

VM Scale Sets are designed for stateless workloads. How should you manage stateful applications that require persistent data?

A Use external storage services like Azure Files or Azure Managed Disks to store application state separately from VMs.

B Store all application data locally on each VM instance's OS disk.

C Disable auto scaling to keep state consistent across instances.

D Use VM Scale Sets without any storage configuration and rely on instance memory.

💡 Hint

Think about separating data from compute to allow scaling.

Storing state externally allows VM instances to be replaced or scaled without losing data, which is essential for stateful apps.