AZ-400 Implement an instrumentation strategy Practice Question
A company has a multi-region application deployed on Azure App Service (Windows) across three regions: West US, East US, and West Europe. The operations team uses Azure Monitor to collect application logs and metrics. Recently, they noticed that the application in West US is experiencing high CPU usage (sustained above 90%) during peak hours, while the other regions remain below 60%. The team has set up an autoscale rule on the App Service plan to scale out when CPU exceeds 80% for 10 minutes. However, autoscale is not triggering, and the application in West US is becoming slow. The team has verified that the autoscale rule is correctly configured, the instance count is below the maximum, and there are no scale-in rules interfering. The metric data appears in Azure Monitor. You suspect that the metric alert that triggers autoscale is not firing. What is the most likely cause?
⚠ Common exam trap
Many exam-takers assume autoscale is failing due to a learning period or data delay, but the real issue is a subtle metric name mismatch that prevents the rule from evaluating the correct data stream.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The autoscale rule is using the wrong metric aggregation or namespace, such as 'CpuTime' instead of 'Percentage CPU'.
The autoscale rule must use the correct metric name and aggregation to evaluate scaling conditions. If the rule is configured with 'CpuTime' instead of 'Percentage CPU', it will not match the actual CPU utilization metric emitted by the Azure App Service plan. 'Percentage CPU' is the standard platform metric for CPU load, while 'CpuTime' measures total CPU time consumed, which does not trigger the same threshold logic. Since the team verified the rule is correctly configured but autoscale is not firing, the most likely cause is a mismatch in the metric name or namespace.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The autoscale rule is using the wrong metric aggregation or namespace, such as 'CpuTime' instead of 'Percentage CPU'.
Why this is correct
Azure autoscale requires the rule to reference the correct resource-specific metric namespace (e.g., Microsoft.Compute/virtualMachineScaleSets for VMSS) and metric name such as 'Percentage CPU' with an aggregation of Average over the evaluated time window; specifying a low-level counter like 'CpuTime' or the wrong namespace prevents the metric signal from being recognized, so the scale-out condition never evaluates to true and no scale operation occurs.
- ✗
The autoscale rule was created less than 24 hours ago and needs a learning period.
Why it's wrong here
Autoscale rules take effect immediately after creation; there is no 24-hour learning period, though the service uses a look-back window (typically the last 10 minutes) of metric data to evaluate the threshold, so short metric history may delay a valid trigger but does not require a full day of warm-up.
- ✗
The metric collection interval for CPU is set to 30 minutes, causing a delay in autoscale evaluation.
Why it's wrong here
Autoscale evaluation is driven by Azure Monitor platform metrics, which are collected and published at a default interval of one minute for supported resources, and the autoscale engine polls these metrics on its own schedule (usually every 1–5 minutes); a separate 'collection interval' of 30 minutes only affects diagnostics/export settings and cannot cause a delay in autoscale because the autoscale engine does not rely on that setting.
- ✗
The autoscale rule is configured to use Log Analytics queries instead of platform metrics.
Why it's wrong here
Autoscale rules are limited to Azure Monitor platform metrics emitted by the underlying resource (such as CPU, memory, or request counts); they cannot directly use Log Analytics queries as a metric source, and attempting to configure a query-based signal would not be accepted, so the rule would not work as designed.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Metric
A metric is a quantifiable measurement used to assess the performance, health, or status of IT systems, networks, or applications.
Key term
Azure Monitor
Azure Monitor is a cloud service that collects, analyzes, and acts on telemetry data from your Azure and on-premises resources to help you understand performance and availability.
About these practice questions
One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.