Auto scaling App Service in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Azure App Service auto scaling react to CPU usage?

You configure auto scaling rules for an Azure App Service based on CPU usage. The rule states: "Scale out by 1 instance when average CPU usage is above 70% for 5 minutes." What happens when the CPU usage spikes to 75% for 6 minutes?

A The App Service scales out by adding one instance after 5 minutes of sustained CPU above 70%.

B The App Service immediately adds one instance as soon as CPU usage exceeds 70%.

C The App Service does not scale out because CPU usage must be above 80%.

D The App Service scales in by removing one instance due to high CPU usage.

💡 Hint

Think about the condition duration and threshold in the scaling rule.

Auto scaling rules trigger actions only after the condition is met for the specified duration. Here, CPU usage above 70% for 5 minutes triggers scaling out by one instance.

❓ Configuration

intermediate

Which JSON snippet correctly configures a scale-out rule based on HTTP queue length?

You want to auto scale your Azure App Service when the HTTP queue length exceeds 100 requests for 10 minutes. Which JSON snippet correctly defines this rule?

A { "metricTrigger": { "metricName": "HttpQueueLength", "threshold": 100, "timeAggregation": "Average", "operator": "GreaterThan", "duration": "PT10M" }, "scaleAction": { "direction": "Increase", "value": "1", "type": "ChangeCount", "cooldown": "PT5M" } }

B { "metricTrigger": { "metricName": "HttpQueueLength", "threshold": 100, "timeAggregation": "Total", "operator": "LessThan", "duration": "PT10M" }, "scaleAction": { "direction": "Decrease", "value": "1", "type": "ChangeCount", "cooldown": "PT5M" } }

C { "metricTrigger": { "metricName": "HttpQueueLength", "threshold": 50, "timeAggregation": "Average", "operator": "GreaterThan", "duration": "PT5M" }, "scaleAction": { "direction": "Increase", "value": "2", "type": "ChangeCount", "cooldown": "PT10M" } }

D { "metricTrigger": { "metricName": "HttpQueueLength", "threshold": 100, "timeAggregation": "Average", "operator": "GreaterThanOrEqual", "duration": "PT15M" }, "scaleAction": { "direction": "Increase", "value": "1", "type": "ChangeCount", "cooldown": "PT5M" } }

💡 Hint

Check the metric name, operator, threshold, and duration carefully.

The rule triggers when the average HTTP queue length is greater than 100 for 10 minutes, increasing instance count by 1 with a cooldown of 5 minutes.

❓ Architecture

advanced

What is the best architecture to ensure zero downtime during App Service scale-out?

You want to scale out your Azure App Service without causing downtime or dropped requests. Which architectural approach ensures this?

A Disable the load balancer during scaling to prevent routing issues.

B Scale out by replacing the existing instance with a new one immediately, causing a brief downtime.

C Use a single instance and increase its size instead of scaling out horizontally.

D Use multiple instances behind the built-in load balancer with health probes to route traffic only to healthy instances.

💡 Hint

Think about how traffic is managed during scaling.

Azure App Service uses a load balancer that routes traffic only to healthy instances, allowing new instances to come online without downtime.

❓ security

advanced

What security risk can arise if auto scaling triggers too frequently on an App Service?

If your Azure App Service auto scaling triggers scale-out and scale-in actions very frequently, what security risk might this cause?

A No security risk because scaling only affects performance, not security.

B Increased attack surface due to frequent instance creation and deletion, possibly exposing misconfigured instances.

C Automatic disabling of firewall rules during scaling events.

D Data loss due to instance termination during scale-in.

💡 Hint

Consider what happens when new instances are created rapidly.

Frequent scaling can create many instances quickly, increasing the chance that some might be misconfigured or not fully patched, increasing attack surface.

✅ Best Practice

expert

Which strategy best prevents scale-out storms in Azure App Service auto scaling?

You notice your Azure App Service scales out rapidly multiple times in a short period, causing instability. Which strategy best prevents this 'scale-out storm'?

A Disable auto scaling and scale manually only during peak hours.

B Set the scale-out threshold to a very low value to trigger scaling earlier.

C Configure a cooldown period after each scale action to delay subsequent scaling operations.

D Increase the maximum number of instances to allow unlimited scaling.

💡 Hint

Think about how to control the frequency of scaling actions.

Cooldown periods prevent rapid repeated scaling by enforcing a wait time after each scale action, stabilizing the system.