Examkin

Question

Difficulty: MediumConfigure Azure Monitor Autoscale Rules and Metrics

A microservice API gateway runs on an Azure App Service plan (Premium V3 tier) that is currently scaled to 44 instances. You configure an autoscale setting with the following scale-out rule:
- Metric: CPU Percentage
- Time grain (aggregation): Average
- Operator: Greater than
- Threshold: 75%75\%
- Action: Increase count by 22

To ensure that the application scales in when load decreases but does not experience scale flapping, you need to configure the scale-in rule. Which of the following scale-in configurations should you use?

  1. Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold: 45%45\%; Action: Decrease count by 22Answer
  2. B
    Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold: 55%55\%; Action: Decrease count by 22
  3. C
    Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold: 40%40\%; Action: Decrease count by 33
  4. D
    Migrate the App Service plan to the Shared tier to automatically enable the built-in dynamic scaling feature.

Answer

Configure the scale-in rule with CPU Percentage, Average time grain, Operator less than, Threshold of 45%45\%, and Action to decrease the count by 22.
The correct scale-in configuration uses a threshold of 45%45\% and decreases the instance count by 22. At the scale-out threshold of 75%75\% CPU on 44 instances, the total workload load is 300%300\%. After scaling out by 22 instances (total of 66), the average CPU load becomes 300%/6=50%300\% / 6 = 50\%. Because the scale-in threshold is set to 45%45\%, the rule will not trigger immediately. If the workload drops enough to trigger the scale-in rule (below 45%45\%, which is less than 270%270\% total workload), scaling in by 22 instances reduces the capacity back to 44 instances. The new average CPU load will be less than 270%/4=67.5%270\% / 4 = 67.5\%, which is safely below the 75%75\% scale-out threshold, preventing flapping.

Step-by-Step Solution

1
Calculate the total workload capacity at the scale-out trigger point.
Total workload is 4 instances×75%=300% CPU capacity4 \text{ instances} \times 75\% = 300\% \text{ CPU capacity}.
We must determine the total CPU resource load consumed just before scaling out.
2
Calculate the average CPU load per instance immediately after scaling out.
New average CPU is 300%/(4+2) instances=50%300\% / (4 + 2) \text{ instances} = 50\%.
This represents the target CPU load under the same workload. The scale-in threshold must be strictly below this value to prevent immediate scale-in.
3
Calculate the maximum safe CPU load when scaling back in from 66 to 44 instances.
The post-scale-in CPU must be less than the scale-out threshold (75%75\%). For 44 instances, total workload must be less than 4×75%=300%4 \times 75\% = 300\%. Across 66 instances, this corresponds to an average CPU of less than 300%/6=50%300\% / 6 = 50\%. A scale-in threshold of 45%45\% (with a decrease of 22) satisfies this condition.
We must verify that scaling back in does not instantly push the average CPU load back above the scale-out threshold, avoiding an infinite loop.

Key Concept

Configuring Azure Monitor autoscale rules to avoid flapping by aligning the scale-out and scale-in thresholds and step sizes.
Rate this question

Topics

Configure Azure Monitor Autoscale Rules and Metrics

More questions from this topic