Microsoft AZ-104: Azure Monitor and Alerting

The current AZ-104 blueprint gives monitoring and maintenance 10–15% of the exam and names a concrete set of administrative tasks: interpret Azure Monitor metrics, configure log settings, query and analyze logs, create alert rules, action groups and alert processing rules, interpret Insights for virtual machines, storage accounts and networks, and use Network Watcher with Connection Monitor. The AZ-104 exam therefore treats monitoring as an operational feedback system, not a dashboard you look at after something breaks.

A useful study model is to separate telemetry collection, analysis, detection, notification, and investigation. Metrics answer fast numerical questions. Logs preserve richer event and diagnostic detail. Alerts evaluate conditions. Action groups decide who or what gets notified. Insights and network tools help interpret resource-specific behavior. Keeping that chain in mind makes configuration questions much easier.

Know when metrics are the right signal

Metrics are numerical time-series data such as utilization, throughput, latency, or counts. They are well suited to questions like “has CPU remained above a threshold?” or “did request volume suddenly fall?” Because metrics are structured for time-based analysis, they are often the fastest signal for health and capacity.

Interpreting a metric means more than noticing a high number. Administrators should consider aggregation, time window, dimensions, and the normal behavior of the resource. A short spike can be harmless while a sustained trend indicates capacity pressure. The same principle applies outside Azure; traditional performance counters and monitoring also become useful only when the operator understands what a measurement means in context.

On the exam, pay attention to the type of evidence requested. If the requirement is a threshold over a numeric signal, metrics are usually a better starting point than a large log query.

Use logs when you need context and history

Logs are better when the question asks what happened, which operation occurred, which identity or component generated an event, or how a sequence unfolded. Azure Monitor can collect platform and resource logs into destinations that support analysis. The blueprint explicitly expects candidates to configure log settings and query and analyze collected data.

Log analysis is powerful because it can correlate multiple fields and time ranges. It is also more expensive operationally if everything is collected without a purpose. A good administrator decides which logs are needed for troubleshooting, security, compliance, or capacity analysis and sets retention and destinations accordingly.

Study the difference between “the data exists” and “the data is queryable where you need it.” A diagnostic setting that never sends the required category to the analysis destination does not help after an incident.

Build alerts from condition to response

An alert rule defines what should be evaluated and when the condition is considered met. An action group defines the response channel, such as notifying people or triggering an automated action. Alert processing rules can alter how alerts are handled during planned maintenance or other operational conditions. These pieces should be understood as a pipeline rather than independent portal objects.

Good alerts are actionable. If a threshold fires constantly during normal load, operators learn to ignore it. If the threshold is too loose, the team discovers the problem from users first. AZ-104 questions can frame this as a configuration decision, but the underlying idea is operational signal quality.

Think about scope and ownership as well. An alert routed to the wrong team is technically generated but operationally ineffective. Action groups should match the people or automation responsible for the resource.

Use Insights to shorten diagnosis

Azure Monitor Insights provide curated views for supported resource types. The current objective specifically calls out monitoring virtual machines, storage accounts, and networks by using Insights. These experiences combine relevant metrics, logs, dependencies, and health data so administrators can move from a broad symptom toward a likely cause more quickly.

Insights are not a replacement for understanding raw telemetry. They are an interpretation layer. When the exam asks which tool gives a focused view of a resource class, Insights may be the answer. When it asks for a custom query across logs, use the underlying log-analysis capability instead.

The same distinction appears in network operations: a summary dashboard is useful, but detailed flow and path evidence may still be required. A conceptual overview of network flow visibility can help reinforce why summarized telemetry and packet-path diagnostics serve different purposes.

Use Network Watcher when the question is the path

Network Watcher and Connection Monitor are named in the current blueprint because resource health alone cannot explain every connectivity failure. A VM may have normal CPU and memory while its application is unreachable because of DNS, NSGs, routes, or a failed endpoint. Network tools focus on reachability and the path between source and destination.

Connection monitoring is particularly useful when the requirement is ongoing validation rather than a one-time manual test. Administrators can detect that a path has degraded or failed even when both endpoints still appear healthy individually.

This is why good troubleshooting combines layers. Azure Monitor may reveal a time-correlated event, while Network Watcher explains the network symptom. The exam often rewards the tool that matches the evidence you are asked to obtain.

Design monitoring around failure questions

Before configuring telemetry, ask what failure you need to detect. Capacity exhaustion, application errors, unauthorized operations, connectivity loss, backup failure, and latency regression produce different evidence. Selecting the signal first prevents a “collect everything and hope” strategy.

For a critical VM, you might monitor resource metrics, collect relevant logs, create alerts for defined conditions, and add network connectivity checks for an application dependency. A storage account may require throughput and availability metrics plus logs for operational investigation. A network issue may require both resource telemetry and path testing.

This layered design is closer to the way administrators actually work than memorizing a menu. It also maps cleanly to the current objective because every named Azure Monitor feature has a role in that evidence chain.

Avoid common alerting mistakes

One mistake is confusing collection with notification. Enabling a diagnostic setting does not create an alert. Another is configuring an alert without a meaningful action group, so the condition is detected but nobody responds. A third is using a broad threshold without a sensible evaluation period and generating noise. A fourth is assuming that an alert proves root cause; it only proves that its condition became true.

Operational teams also need maintenance awareness. Alert processing rules can prevent planned work from flooding responders with expected notifications. That does not mean suppressing every warning during maintenance; critical signals still need an intentional handling policy.

The general monitoring ecosystem includes many products, including the network monitoring tools used in traditional environments. For AZ-104, keep the answer anchored to Azure Monitor, Insights, Network Watcher, and the exact resource requirement.

Practice from symptom to evidence

Take a scenario and ask which evidence would prove or disprove the suspected problem. Sustained VM CPU saturation points to metrics. A sequence of failed operations points to logs. A requirement to notify the operations team when a condition persists points to an alert plus action group. Intermittent network reachability points toward Connection Monitor. A resource-specific performance overview may point to Insights.

This approach turns monitoring questions into evidence-selection questions. You do not need to memorize every Azure Monitor screen. You need to know which telemetry type and operational feature can answer the question the administrator is facing.

When you can move confidently from signal to query to alert to investigation, the monitoring domain becomes one of the most practical parts of AZ-104 rather than an abstract collection of observability terms.

Balance telemetry depth with retention and cost

Monitoring design has an economic side. Collecting every possible log category forever can create unnecessary cost and make analysis noisier, while collecting too little leaves the team blind during an incident. Administrators should identify which telemetry supports operations, security, compliance, and troubleshooting, then choose sensible destinations and retention periods for each need.

Metrics and logs can also have different retention and query characteristics, so the data source should match the investigation horizon. A short-lived performance spike might be visible in metrics, while a compliance investigation may require durable logs that preserve who changed a resource and when. The blueprint’s emphasis on both metrics and logs reflects this operational distinction.

Alert design should follow the same principle. Not every signal deserves immediate paging. Some conditions can be reported for trend review, while others require rapid action. A mature Azure Monitor configuration separates informational telemetry from actionable conditions and makes the response expectation clear to the team that receives the alert.

Correlate alerts with deployment and configuration changes

Monitoring becomes more useful when operational events are interpreted alongside recent changes. A latency spike immediately after a deployment, route update, or scaling change suggests a different investigation path than the same spike occurring with no known change. Administrators should use timestamps, activity history, deployment records, and log evidence to build a timeline instead of treating every alert as an isolated event.

This is especially valuable during incident response because rollback can be faster than broad troubleshooting when a newly introduced change clearly caused the problem. The alert tells you when the condition appeared; the change history helps explain why.