A healthy Azure resource and a healthy application are not the same thing. A virtual machine can show a running power state while its application is unreachable; an alert can fire correctly while the notification goes to the wrong team; a backup can complete without proving the service is restorable. These distinctions make Azure Monitor one of the most useful operational topics in Microsoft AZ-104.

This walkthrough follows a small fictional application incident from symptom to evidence, alerting, ownership and recovery. You’ll decide which signals belong in metrics, which need queryable logs, how an action group should route an incident, and when Network Watcher or backup evidence is necessary. The examples are illustrative design exercises; they have not been run in the reader’s tenant.

Microsoft’s current AZ-104 objective area Monitor and maintain Azure resources accounts for 10–15 percent of the blueprint. Use AZ-104 exam preparation resources to check your understanding and the AZ-104 learning center to connect monitoring decisions with identity, networking, compute and storage. The purpose of this article is a different, practical task: make an alert useful when something actually goes wrong.

Start with an incident that has a measurable outcome

Suppose an inventory web application runs on a test virtual machine, retrieves records from storage and serves requests through a configured network path. A user reports that the application is timing out. Your deployment dashboard shows the VM is running. That observation rules out some possibilities, but not DNS, an NSG rule, application crashes, disk saturation, incorrect credentials or an unhealthy dependency.

Write a concise incident question before opening the Azure portal: Did the application stop serving requests, did its dependency become unreachable, or did clients lose the path to it? The right monitor depends on the answer you need. CPU percentage can indicate resource pressure but will not tell you which private endpoint name a process tried to resolve. A recorded application error can show a failed request but may not reveal the effective route used by the network.

For a safe lab, use a non-production resource group with a known resource owner, a bounded test budget and a planned cleanup. Record the resource identifier, subscription, location and time window. A metric and an activity log entry with the same resource display name could still refer to different objects after a replacement deployment, so preserve the durable identity and observation time.

The table prevents a common first response: choosing the most familiar dashboard instead of selecting the data source that answers the question. When a signal is missing, treat it as a data-collection or scope problem until you have evidence that the resource itself has failed.

Metrics, resource logs and the Activity Log have different jobs

Azure Monitor platform metrics describe numeric behavior over time, usually with a particular aggregation and granularity. A VM CPU metric can show how utilization changed in a five-minute window. Because metrics are numeric, they work well for a condition such as “the five-minute average is persistently above a threshold.” A point value without its unit, period and aggregation can be misleading; a maximum and an average may tell different stories during a burst.

Azure resource logs provide service-specific events and details when collection is enabled. They aren’t all automatically retained in a queryable Log Analytics workspace. A diagnostic setting can route supported resource log categories to a destination such as a Log Analytics workspace, storage account or Event Hubs. The available categories depend on the Azure service. Configuring the setting only after an incident does not reconstruct events that were never collected.

The Azure Activity Log focuses on subscription-level management and other control-plane events. It may identify that someone modified a VM or policy, but it is not a substitute for application transaction logging. Exporting activity events into a workspace for additional query or retention purposes also requires the appropriate subscription-level configuration. Do not assume every Azure Monitor view reads from the same storage location.

For the lab, choose one platform metric, one relevant resource log category supported by your test service and one control-plane change to examine in the Activity Log. Document their respective scopes, data-collection paths and expected delays. Compare what appears immediately in the resource’s Metrics view with what becomes queryable later in the workspace.

Build the collection path before writing a query

A Log Analytics workspace stores collected log records so you can filter and aggregate them through Kusto Query Language (KQL). It does not automatically ingest arbitrary guest operating-system logs just because the workspace exists. Depending on the source, collection may require an Azure Monitor Agent and a Data Collection Rule, a service diagnostic setting, or another supported route. Microsoft explains the query experience in its Log Analytics documentation.

Consider the sample query below. It asks for recent Heartbeat records grouped by computer. It works only if heartbeat data from an appropriate collection path is present in that table. It is not a universal test of whether a VM is currently running. Empty results could mean no agent, no rule, a scope or permission problem, ingestion delay, or a real outage.

// Sample KQL — run only where Heartbeat records are collected
Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastSeen = max(TimeGenerated) by Computer
| order by LastSeen desc

Validate the result against the source VM and time. In a real environment, make the query’s machine identifiers and workspace scope explicit. A high-stakes automation should not shut down or restore infrastructure merely because this one table contains no recent row.

Build an alert rule that describes a decision

An Azure Monitor alert rule joins three core concepts: monitored scope, a signal, and a condition. It can evaluate metrics or queried log data. The rule may carry severity, frequency, evaluation window and state behavior; none of these is just decoration. The same CPU measurement can cause very different operational noise if one rule fires on a single peak and another requires sustained pressure.

In the test VM, select a supported CPU metric and inspect its recent chart. Before choosing a threshold, note the normal range for that workload and what impact elevated utilization would actually cause. For an illustrative policy, suppose the team investigates sustained CPU usage above 85 percent over several measurements. The exact threshold is a lab choice, not a Microsoft-recommended universal default. Check the resource’s supported metrics and ensure that your evaluation frequency and aggregation are internally consistent.

Static thresholds are straightforward when you have a known limit. Dynamic thresholds instead learn historical patterns and flag changes relative to normal behavior. Microsoft notes important caveats in its dynamic-threshold guidance: some rules need at least three days and 30 samples before alerting, and slowly drifting problems might not stand out like abrupt anomalies. Do not choose an adaptive threshold merely because it sounds more intelligent. A brand-new test VM may not have enough baseline data for the behavior you expect.

If your monitor covers several resources or metric dimensions, decide whether one rule should evaluate each relevant series or whether the requirement is truly one aggregate. An alert about failed storage transactions by response type, for example, must not silently combine different outcomes into a meaningless average. Test the condition against known historical data rather than assuming your first choice is tuned.

Connect the rule to an action group and a responsible person

An alert that fires correctly and reaches nobody has not delivered operational value. In Azure Monitor, an action group defines who is notified and which automated actions can run. Depending on the configuration, it can send email or other notifications, invoke a webhook, or start a supported workflow. Multiple alert rules can reuse an action group. The action group is not the metric condition itself, and an email address written in a runbook is not a substitute for a configured action path.

For the lab, create a non-production notification target and attach it to the test metric rule. Use a clear severity and description that contain the resource identity, the measured symptom and the intended investigation path. Confirm the action group test and a real controlled alert path if the environment permits it. Record which signal triggered the alert, when it fired, when the notification arrived and whether the team could locate the affected resource.

A notification is not always the final response. If you configure automation, require scoped permissions and idempotent behavior, especially when an alert remains active or fires again after a deployment. Automatically rebooting every VM that shows high CPU may suppress useful evidence and turn a recoverable application fault into an outage. A safer initial workflow may create an incident with linked context and seek an authorized operational decision.

Azure Monitor also distinguishes the technical alert condition from the human response state, such as New, Acknowledged or Closed. An operator can acknowledge an investigation without the underlying resource returning to healthy operation. Similarly, closing an incident in a ticketing system doesn’t prove that the metric rule has resolved. Make the meaning of these states explicit in your runbook.

Why an alert sometimes does not fire

Suppose the VM visibly exceeded your chosen threshold, but no alert appeared. Avoid immediately lowering the threshold or creating a second copy of the rule. Inspect whether the right resource and metric were selected, whether the aggregation/granularity matches the observed chart, whether the rule is enabled, and whether sufficient data was available during the evaluation window. With a dynamic rule, check whether its learning period and sample minimum were met.

If an alert fired but no message arrived, inspect the action group, notification target, suppression/processing rules and any documented rate limits. Microsoft treats alert conditions and alert processing as distinct control points. A delivery problem and a detection problem have different owners. Changing the original signal condition to fix an email-routing issue creates a new defect rather than solving the old one.

Use Network Watcher when the evidence points to connectivity

Return to the original inventory application. Its VM appears healthy and the metrics are ordinary, but the client cannot reach a storage endpoint. That is a signal to inspect connectivity, not to add another CPU alert. Azure Network Watcher provides diagnostic tools for distinct questions. IP flow verify evaluates whether applicable network security rules allow or deny a specified packet; effective security rules show the rules on a network interface; next hop analyzes the route to a destination; and connection troubleshoot combines reachability tests with routing and security evidence.

Microsoft’s connection troubleshoot reference describes how to target a VM, address or FQDN and inspect whether the connection is reachable, which hops were used and why a failure occurred. Some agentless diagnostic capabilities are in preview, so verify supported resource and tool prerequisites before assuming a feature behaves the same in every tenant.

Run a safe read-only diagnosis for one source/destination pair at a time. Start with the destination FQDN and the resolved address. If the address points to the wrong private endpoint or a public address when a private path is required, changing an NSG rule might be irrelevant. If name resolution is correct, evaluate the effective route and security rules. If the path appears open yet the service still fails, inspect the application protocol, credentials and backend health. A successful TCP probe can demonstrate reachability at that layer but cannot certify the business transaction.

The existing AZ-104 virtual networking guide explains these network layers broadly, while private endpoint DNS troubleshooting focuses on the name-resolution trap. The Network Watcher practice test lets you reason about diagnostic tool selection. This walkthrough shows when monitoring evidence should trigger that deeper investigation, not how to memorize the tool menu.

Recover the service, then prove users can work

A correct incident response is more than removing the symptom. If a storage access rule was wrong, restore the intended configuration with the narrowest authorized change, confirm the actual application data operation succeeds and document any security consequence. If a VM or disk must be recovered, examine the available recovery point, restore target and access constraints. A completed operation may bring the resource online without putting it back into the correct network or application configuration.

Azure Backup and Azure Site Recovery should not be treated as interchangeable. Backup focuses on recoverable copies and retention; Site Recovery supports replication and failover for supported workloads with different recovery-objective trade-offs. The existing backup and recovery design article describes those decisions in more depth. Here, integrate recovery evidence into monitoring: what alert should indicate failure, who receives it, who has permission to act and which observable service-level check establishes success?

Write an incident handoff with four facts: exact affected resource and timestamp; signal and confidence level; controlled action and approval; independent result verification. If you only have a possible cause, label it a hypothesis. If restoring one service depends on a separate DNS, route or identity change, identify the dependency before announcing recovery. Clear provenance and bounded escalation make operations more predictable even when the first diagnosis is wrong.

Rehearse one end-to-end AZ-104 Monitor scenario

Build a compact simulation with known expectations. In a lab subscription, configure a monitoring signal for a test resource, an action group directed to a controlled endpoint, and a workspace-based log query only if the required collection route is actually set up. Trigger an allowed change and see whether the expected condition appears. Then deliberately break one component—for example, use the wrong workspace time range or remove a test notification target—and diagnose that failure without editing several settings at once.

Write down the timeline: source event; when the signal appeared; when the alert evaluated; when the notification arrived; what the responder observed; and how normal behavior was confirmed. Compare the gap between event and notification with the requirements of the service. Be explicit about potential ingestion and polling delays; a minute on a dashboard is not automatically real-time detection. If a rule has no evidence window, first fix the measurement rather than guessing about the alerting service.

Afterward answer these six questions in prose: What exactly was unhealthy? Which measurement showed it? Which source could independently confirm the measurement? What rule decided it mattered? Who received responsibility? What observed result justified marking it resolved? If you cannot answer one, that is the missing part of the monitoring design.

Finally remove the test resources, diagnostic settings, alert rules and workspace data or configuration according to the lab’s retention requirements. Unnecessary logging and alert evaluations can create cost, and a forgotten action group can send misleading notifications after the original tester leaves. Cost and ownership are part of Azure administration, not optional housekeeping.

What a strong AZ-104 answer demonstrates

When a scenario asks for a sustained numeric anomaly, consider the correct metric, aggregation and alert condition. When it asks for the cause of service-specific failures, first establish which logs are collected and queryable. When it describes missing notifications, troubleshoot the action group rather than tuning the metric. When network reachability is uncertain, choose a diagnostic that tests the suspected layer. And when recovery is claimed, demand evidence that the intended workload actually works again.

Those are different administrative decisions. The shortest correct answer is the one that fixes the right boundary while leaving unrelated resources and controls unchanged. Use the Azure Monitor practice questions and backup and recovery questions to test the distinctions, then reproduce the relevant observation in your lab rather than relying only on a remembered answer.

The larger AZ-104 goal is operational judgment: measure an Azure condition with the right source, evaluate it consistently, notify the responsible team, respond within authorized scope and verify recovery with independent evidence. A metric, a dashboard or a green backup icon is a part of that process, not the complete system.