An organization deploys a background processing application to an Azure App Service Plan i… — Microsoft Azure Developer (AZ-204)

An organization deploys a background processing application to an Azure App Service Plan in the East US region. The application processes tasks from an Azure Service Bus queue named `task-queue` in the same region.

To handle spikes in workload, you configure an autoscale setting on the App Service Plan with the following scale-out rule:
- Metric source: Service Bus Queue (`task-queue`)
- Metric name: `ActiveMessages`
- Time Grain (Frequency): $1$ -minute
- Time Window: $10$ -minutes
- Time Aggregation: `Total`
- Operator: `GreaterThan`
- Threshold: $500$
- Scale Action: Increase count by $2$

During a period of stable, low traffic, the queue maintains a steady backlog of approximately $60$ active messages. However, you observe that the App Service Plan unexpectedly scales out to its maximum instance count.

Which of the following is the root cause of this unexpected scaling behavior?

A
The App Service Plan and the Service Bus namespace are located in the same region, which causes a routing conflict for Azure Monitor cross-resource metrics.
The `Total` time aggregation sums the samples over the $10$ -minute window, resulting in an evaluated metric value of approximately $600$ , which exceeds the threshold of $500$ .Answer
C
The `ActiveMessages` metric is a cumulative counter that only increases, meaning any aggregation other than `Average` will fail to compute the rate of change.
D
Scaling an App Service Plan based on external Service Bus metrics is unsupported on standard hosting plans, requiring an Isolated App Service Environment.

Answer

The scale-out rule triggers because the 'Total' time aggregation sums the samples of the queue size (approximately

60

messages) over the

10

-minute window (

10

samples of

1

minute each), resulting in an evaluated value of approximately

600

, which exceeds the threshold of

500

The correct answer is correct because using the 'Total' time aggregation sums the point-in-time samples of the queue size (approximately

60

messages) over the

10

-minute window (

10

samples of

1

minute each), resulting in an aggregated value of approximately

600

. Since this value exceeds the threshold of

500

, it triggers the scale-out action. To monitor queue lengths correctly, 'Average' or 'Maximum' aggregation must be used.

Step-by-Step Solution

Analyze the sampling rate and the time window of the autoscale metric trigger.

The rule uses a Time Grain (frequency) of

1

minute and a Time Window of

10

minutes, meaning

10

metric samples are collected and evaluated during each autoscale check.

To understand how the metric value is calculated, we must determine the number of samples collected within the evaluation window.

Calculate the aggregated metric value based on the 'Total' Time Aggregation type and the steady backlog.

Under a stable workload of

60

messages, each of the

10

samples has a value of approximately

60

. Using 'Total' aggregation, the sum of these samples is calculated:

60 \times 10 = 600

The 'Total' aggregation sums all samples in the time window rather than taking the average, minimum, or maximum value.

Compare the aggregated metric value against the configured scale-out threshold.

The calculated value of

600

is compared to the threshold of

500

. Since

600 > 500

, the operator GreaterThan is satisfied, and the scale-out action (Increase count by

2

) is triggered.

This explains why the App Service Plan scales out to its maximum instance count even under low, stable traffic.

Key Concept

Azure Monitor Autoscale Cross-Resource Metrics and Time Aggregation Types

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic