An organization hosts a processing-heavy application named FlightDataAnalyzer on an Azure … — Microsoft Azure Developer (AZ-204)

An organization hosts a processing-heavy application named FlightDataAnalyzer on an Azure App Service Web App. The application currently runs on a Standard (S2) App Service plan. During daily data aggregation runs at 04:00 UTC, the application experiences a rapid spike in memory usage, causing performance degradation. You want to implement an autoscale setting with a scale-out rule that increases the instance count by 1 when the Memory Percentage exceeds $80\%$ . To minimize costs, you must also define a scale-in rule that decreases the instance count by 1 when load drops, while ensuring the system does not experience flapping when scaling between 1 and 2 instances. Which two configurations should you apply to meet these requirements? (Select TWO.)

Configure a scale-out rule based on the Memory Percentage metric with a threshold of $80\%$ .Answer
Configure a scale-in rule based on the Memory Percentage metric with a threshold of $35\%$ .Answer
C
Configure a scale-in rule based on the Memory Percentage metric with a threshold of $55\%$ .
D
Scale down the App Service plan to the Basic (B2) tier before configuring the autoscale rules.

Answer

Configure a scale-out rule based on the Memory Percentage metric with a threshold of 80%, and configure a scale-in rule based on the Memory Percentage metric with a threshold of 35%.

To handle the memory spike, a scale-out rule must be configured to trigger at

80\%

Memory Percentage. To prevent flapping when scaling between 1 and 2 instances, the scale-in threshold must be set below the post-scale-out load level. If 1 instance runs at

80\%

memory, scaling out to 2 instances redistributes the load to approximately

40\%

per instance. Therefore, a scale-in threshold of

35\%

is safe because it is below

40\%

, whereas a threshold of

55\%

would trigger immediate scale-in and cause flapping.

Step-by-Step Solution

Analyze the scaling metric and autoscale capability of the current hosting plan.

The application runs on a Standard (S2) App Service plan, which supports autoscaling. The load spike is memory-bound, so the Memory Percentage metric is the correct scaling metric.

Ensures that the resource metrics match the bottleneck and that the plan tier supports automated scaling.

Calculate the post-scale-out load level to prevent flapping.

At the scale-out threshold of

80\%

memory usage with 1 instance, a scale-out event adds 1 instance (total of 2). The load is redistributed, dropping the memory usage per instance to approximately

40\%

(calculated as

80\% \times 1 / 2

Prevents the system from entering a flapping loop where scale-in is triggered immediately after scale-out.

Determine the correct scale-in threshold.

The scale-in threshold must be set below

40\%

to prevent flapping. A threshold of

35\%

is safe, while a threshold of

55\%

is too high and would trigger immediate scale-in.

Ensures stable scaling behavior under load.

Key Concept

Azure App Service autoscale rules require careful configuration of scale-in thresholds relative to scale-out thresholds to prevent flapping, and they require a pricing tier (Standard or higher) that supports autoscaling.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic