An organization runs a web API on an Azure App Service plan that currently has a capacity … — Microsoft Azure Developer (AZ-204)

An organization runs a web API on an Azure App Service plan that currently has a capacity of $2$ instances. You need to configure Azure Monitor autoscale rules to scale the application. The scale-out rule must add $2$ instances when the average CPU percentage over a $10$ -minute time window exceeds $80\%$ . To prevent resource flapping while optimizing costs, you must configure a scale-in rule that decreases the instance count by $1$ when CPU usage drops. Which configuration successfully supports custom autoscale rules and prevents rule flapping?

A
Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to $80\%$ CPU to add $2$ instances, and set the scale-in threshold to $45\%$ CPU to decrease the instance count by $1$ .
B
Host the application on a Basic (B1) App Service plan. Set the scale-out threshold to $80\%$ CPU to add $2$ instances, and set the scale-in threshold to $30\%$ CPU to decrease the instance count by $1$ .
Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to $80\%$ CPU to add $2$ instances, and set the scale-in threshold to $30\%$ CPU to decrease the instance count by $1$ .Cevap
D
Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to $80\%$ CPU to add $2$ instances, and set the scale-in threshold to $50\%$ CPU to decrease the instance count by $1$ .

Cevap

Host the application on a Standard (S1) App Service plan. Set the scale-out threshold to

80\%

CPU to add

2

instances, and set the scale-in threshold to

30\%

CPU to decrease the instance count by

1

The correct configuration uses the Standard (S1) App Service plan, which supports custom autoscale rules. It also prevents autoscale flapping by setting the scale-in threshold to

30\%

. At the scale-out threshold of

80\%

, the

2

instances have a total CPU load of

160\%

. Adding

2

instances increases the total to

4

instances, reducing the average CPU per instance to

40\%

. A scale-in threshold of

30\%

is below this post-scale average, ensuring that scaling in is not triggered immediately after scaling out.

Adım Adım Çözüm

Identify the minimum App Service plan tier required to support custom autoscale rules.

The Standard (S1) tier or higher is required. The Basic (B1) tier does not support custom autoscale rules based on metrics.

Autoscale is a feature of Standard and Premium App Service plans, so any option using a Basic plan is incorrect.

Calculate the total CPU workload at the point of scale-out.

With

2

instances running at

80\%

CPU, the total CPU workload is

2 \times 80\% = 160\%

of a single instance's capacity.

This total workload will be distributed among the new set of instances after the scale-out event.

Calculate the average CPU per instance immediately after the scale-out event.

The scale-out rule adds

2

instances, increasing the total count to

4

. The average CPU per instance becomes

160\% / 4 = 40\%

Knowing the post-scale-out CPU load helps determine the maximum threshold for the scale-in rule to prevent flapping.

Determine a scale-in threshold that prevents immediate scale-in (flapping).

The scale-in threshold must be strictly less than

40\%

. A threshold of

30\%

satisfies this condition, while thresholds of

45\%

50\%

would trigger an immediate scale-in.

If the scale-in threshold is greater than or equal to

40\%

, the autoscale engine will immediately scale back down after scaling up, causing an loop of scaling (flapping).

Anahtar Kavram

Preventing autoscale flapping and choosing the correct hosting tier for Azure Monitor autoscale rules.

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru