Your product API must page the on-call engineer when its average server response time stays above two seconds across a rolling five-minute window. Which Azure Monitor configuration does this with the least delay?
Show answer and explanation
Answer: A
Metric alerts evaluate a numeric time series at a short frequency, so they respond quickly and cost less than log alerts. Selecting the server response time metric, Average aggregation, a static threshold of 2000 ms, and a five-minute window matches the requirement exactly. The alert can trigger an action group that pages the on-call engineer. Log alerts suit conditions needing richer filtering, and Smart Detection is intentionally adaptive rather than threshold based.
Why the other options are wrong
- B. A log alert can express the same condition in KQL, but it runs a query on a schedule and is heavier than a metric alert. For a simple average threshold on an existing metric, the metric alert is the direct choice.
- C. Smart Detection flags unusual patterns against learned baselines and does not use a fixed two-second threshold. It cannot guarantee a page at the exact rule the team specified.
- D. Availability tests measure responses from synthetic probes at chosen locations, not the average of real user traffic. A slow probe does not prove the production API is slow for every caller.