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.

Practice

1. What is the main purpose of auto scaling in Azure App Service?

easy

A. Automatically adjust app resources based on demand

B. Manually increase server size when needed

C. Backup app data to cloud storage

D. Monitor user login activities

Solution

1. Step 1: Understand auto scaling concept

   Auto scaling means the system changes resources automatically without manual intervention.

2. Step 2: Identify the purpose in Azure App Service

   Azure App Service auto scaling adjusts the number of instances based on app demand to maintain performance and control costs.

3. Final Answer:

   Automatically adjust app resources based on demand -> Option A

4. Quick Check:

   Auto scaling = automatic resource adjustment [OK]

Hint: Auto scaling means automatic resource changes [OK]

Common Mistakes:

• Confusing auto scaling with manual scaling
• Thinking auto scaling backs up data
• Assuming auto scaling monitors user activity

2. Which of the following is the correct way to set a CPU-based auto scale rule in Azure App Service?

easy

A. Set a rule to scale in when CPU usage < 90%

B. Set a rule to scale out when memory usage < 30%

C. Set a rule to scale out when CPU usage > 70%

D. Set a rule to scale out when disk space > 80%

Solution

1. Step 1: Identify correct metric for scaling out

   CPU usage is a common metric to trigger scaling out when it exceeds a threshold.

2. Step 2: Check the threshold and direction

   Scaling out happens when CPU usage is high (e.g., > 70%), not low or unrelated metrics like disk space.

3. Final Answer:

   Set a rule to scale out when CPU usage > 70% -> Option C

4. Quick Check:

   Scale out triggers on high CPU [OK]

Hint: Scale out when CPU usage is high, not low [OK]

Common Mistakes:

• Using memory or disk space incorrectly for CPU scaling
• Scaling in when CPU is still high
• Setting wrong thresholds for scaling

3. Given this auto scale setting: minimum instances = 2, maximum instances = 5, scale out rule triggers at CPU > 60%, scale in rule triggers at CPU < 30%. If CPU usage rises from 50% to 65%, what happens?

medium

A. Instances reset to minimum count immediately

B. The number of instances increases by one, up to 5

C. No change in instances because CPU is below 70%

D. The number of instances decreases by one, down to 2

Solution

1. Step 1: Analyze CPU usage against scale out rule

   CPU rose from 50% to 65%, which is above the 60% threshold for scaling out.

2. Step 2: Apply scaling limits

   Instances will increase by one but will not exceed the maximum of 5 instances.

3. Final Answer:

   The number of instances increases by one, up to 5 -> Option B

4. Quick Check:

   CPU > 60% triggers scale out [OK]

Hint: Scale out triggers when CPU crosses threshold upwards [OK]

Common Mistakes:

• Thinking CPU must be above 70% to scale out
• Confusing scale in and scale out rules
• Assuming immediate reset to minimum instances

4. You configured auto scaling with minimum 1 instance and maximum 3 instances. The scale out rule triggers at CPU > 50%. However, your app never scales out even when CPU is 80%. What is the most likely issue?

medium

A. CPU metric is not supported for scaling

B. The minimum instance count is too high

C. Maximum instance count is set too low

D. The scale out rule is disabled or not linked to the App Service

Solution

1. Step 1: Check if scaling rules are active

   If the scale out rule is disabled or not properly linked, scaling won't trigger despite high CPU.

2. Step 2: Verify instance limits and metric support

   Minimum and maximum instance counts are valid, and CPU is a supported metric, so these are unlikely causes.

3. Final Answer:

   The scale out rule is disabled or not linked to the App Service -> Option D

4. Quick Check:

   Active rules needed for scaling [OK]

Hint: Check if scaling rules are enabled and linked [OK]

Common Mistakes:

• Assuming instance counts block scaling
• Believing CPU metric is unsupported
• Ignoring rule activation status

5. You want to optimize costs by setting auto scaling for your Azure App Service. You set minimum instances to 1 and maximum to 10. You add a scale out rule for CPU > 70% and a scale in rule for CPU < 40%. However, during peak hours, your app scales out to 10 instances quickly but never scales in after peak hours. What is the best way to fix this?

hard

A. Add a cooldown period to delay scaling in after peak hours

B. Increase the minimum instance count to 5

C. Remove the scale out rule to prevent scaling beyond 1 instance

D. Set scale in rule to CPU < 80% to scale in faster

Solution

1. Step 1: Understand why scaling in doesn't happen

   Without a cooldown period, rapid fluctuations can prevent scale in or cause instability.

2. Step 2: Apply cooldown period to stabilize scaling

   Adding a cooldown period delays scale in, allowing CPU to stay below threshold steadily before reducing instances.

3. Final Answer:

   Add a cooldown period to delay scaling in after peak hours -> Option A

4. Quick Check:

   Cooldown stabilizes scale in/out actions [OK]

Hint: Use cooldown to prevent rapid scale in/out flips [OK]

Common Mistakes:

• Raising minimum instances unnecessarily
• Removing scale out rule stops scaling out
• Setting scale in threshold too high causes no scale in