hardmultiple choiceObjective-mapped

An operations team manages an Azure virtual machine scale set that hosts a stateless API. They already collect guest logs in Log Analytics, but they do not want to ingest extra performance data just to watch CPU. They need an alert when average CPU across the scale set stays above 80% for 10 minutes, and the notification must support email and a webhook. What should they configure?

Question 1hardmultiple choice
Full question →

An operations team manages an Azure virtual machine scale set that hosts a stateless API. They already collect guest logs in Log Analytics, but they do not want to ingest extra performance data just to watch CPU. They need an alert when average CPU across the scale set stays above 80% for 10 minutes, and the notification must support email and a webhook. What should they configure?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

Create a diagnostic setting on the scale set and build a log query alert for CPU samples.

This sends or queries data after ingestion and is unnecessary for a native CPU threshold.

B

Best answer

Create an Azure Monitor metric alert on the scale set CPU metric and attach an action group.

Metric alerts evaluate platform metrics directly, so no extra log ingestion is needed. An action group is the correct notification mechanism for email, webhook, SMS, or other responses. This design is the lowest-overhead way to detect sustained CPU pressure on a VM scale set and notify operators quickly.

C

Distractor review

Configure an autoscale rule and rely on its notification settings for alerting.

Autoscale can react to load, but it is not the best fit for a dedicated operational alert requirement.

D

Distractor review

Install a monitoring extension that writes CPU readings to storage for later review.

Writing custom CPU samples to storage adds management overhead and does not provide native Azure alerting behavior.

Common exam trap

Common exam trap: NAT rules depend on direction and matching traffic

NAT is not only about the public address. The inside/outside interface roles and the ACL or rule that matches traffic are just as important.

Technical deep dive

How to think about this question

NAT questions usually test address translation, overload/PAT behaviour, static mappings and whether the right traffic is being translated. Read the interface direction and address terms carefully.

KKey Concepts to Remember

  • Static NAT maps one inside address to one outside address.
  • PAT allows many inside hosts to share one public address using ports.
  • Inside local and inside global describe the private and translated addresses.
  • NAT ACLs identify traffic for translation, not always security filtering.

TExam Day Tips

  • Identify inside and outside interfaces first.
  • Check whether the scenario needs static NAT, dynamic NAT or PAT.
  • Do not confuse NAT matching ACLs with normal packet-filtering intent.

Related practice questions

Related AZ-104 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

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: Create an Azure Monitor metric alert on the scale set CPU metric and attach an action group. — Azure Monitor metric alerts are the best choice when you need a threshold-based alert on a built-in platform metric such as CPU. The alert can evaluate directly against the scale set metric without sending additional data to Log Analytics. An action group then delivers email and webhook notifications. This satisfies the requirement to keep telemetry ingestion costs low while still alerting on sustained high CPU. Why others are wrong: Diagnostic settings and log queries are unnecessary because CPU is already exposed as a platform metric. Autoscale can change capacity, but it is not a general alerting solution and may not provide the exact notification workflow requested. A custom extension that writes CPU readings to storage is operationally heavier, delays alerting, and does not use Azure Monitor’s native metric-alert path.

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.

Discussion

Loading comments…

Sign in to join the discussion.