The operations team wants an email and SMS notification whenever any production virtual machine's average CPU stays above 85 percent for 10 minutes. They also want to reuse the same notification targets for future alerts. What should they configure?

A diagnostic setting on each VM that sends metrics to a storage account

Diagnostic settings export telemetry for later analysis, but they do not define reusable notification endpoints or alert thresholds.

A Log Analytics query alert with no notification target

A query alert can evaluate logs, but it still needs an action target, and it is not the most direct choice for a simple CPU metric condition.

A resource lock on the virtual machines

A lock can prevent changes or deletion, but it cannot evaluate CPU usage or send operational notifications.

What does this AZ-104 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: An action group attached to a metric alert rule — A metric alert is the correct monitoring mechanism because CPU percentage is an Azure Monitor metric, not a log event. The action group provides reusable notification channels such as email and SMS, so it can be attached to multiple alerts later. This combination satisfies both requirements: detect sustained high CPU and reuse the same notification targets across the environment. Why others are wrong: Diagnostic settings are for exporting logs and metrics, not for alert delivery. A Log Analytics query alert is more appropriate when the condition comes from a KQL query over logs, not a native VM metric. A resource lock is unrelated to monitoring and cannot trigger notifications.

What should I do if I get this AZ-104 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.