Use Azure Monitor, Insights, and Alerting for AZ-104

Azure Monitor is where AZ-104 expects administrators to turn raw platform behavior into usable signal. The exam is not asking whether telemetry exists. It is asking whether you can choose the right telemetry path and wire it into an operational response.

What Microsoft explicitly includes

The current outline covers interpreting metrics, configuring log settings, querying and analyzing logs, setting up alert rules, action groups, and alert processing rules, and using Azure Monitor Insights for VMs, storage accounts, and networks.

The model that keeps the tools straight

Metrics are lightweight numerical signals that work well for fast thresholds such as CPU or request counts. Logs are richer event and state records that support investigation and correlation. Insights packages useful views over common resource types. Alert rules decide when a condition matters. Action groups decide what happens next.

Common traps

Many candidates mix up diagnostic settings, activity logs, and Log Analytics data flow. Another frequent miss is choosing a metric alert for a question that really needs log correlation or choosing a log query when a simple metric threshold would have been faster and more reliable.

Lab moves worth practicing

• create one metric alert and attach an action group
• send resource logs to a Log Analytics workspace and run a basic KQL query
• inspect Azure Monitor Insights for a VM or network resource

Signal chooser

Telemetry map

Monitoring signal flow

When candidates mix up Monitor components, it is usually because they lose track of where the signal starts and where the response happens.

    flowchart LR
	  R["Azure resource"] --> M["Metrics"]
	  R --> D["Diagnostic settings"]
	  D --> L["Log Analytics / resource logs"]
	  M --> A["Alert rule"]
	  L --> A
	  A --> AG["Action group"]
	  L --> I["KQL investigation / Insights"]

The diagram is showing two different routes:

• a fast alerting route from metrics or logs into an alert rule and then an action group
• an investigation route where logs feed KQL analysis or Insights views

Diagnostic settings versus the data you query

Candidates often know that logs exist but lose track of how they get there.

The practical sequence is: configure the data path first, then query or alert on the data that is actually being collected.

Azure CLI example: metric alert and action group

 1az monitor action-group create \
 2  --resource-group app-rg \
 3  --name ops-ag \
 4  --action email Ops ops@example.com
 5
 6az monitor metrics alert create \
 7  --resource-group app-rg \
 8  --name cpu-high \
 9  --scopes /subscriptions/<sub>/resourceGroups/app-rg/providers/Microsoft.Compute/virtualMachines/web-01 \
10  --condition "avg Percentage CPU > 80" \
11  --window-size 5m \
12  --evaluation-frequency 1m \
13  --action-group ops-ag

This example is useful because it separates the two roles clearly:

• the alert rule decides when the condition is true
• the action group decides who gets notified or which response path runs

One small KQL example

This is the kind of query shape you should be able to read even if you do not write KQL every day:

AzureActivity
| where TimeGenerated > ago(24h)
| summarize Count=count() by OperationNameValue, ActivityStatusValue
| order by Count desc

The point is not memorizing every operator. The point is recognizing that logs can summarize and investigate control-plane history in a way a metric alert cannot.

Quiz

Continue with Backup, Site Recovery, and Network Watcher so monitoring ties back to actual recovery operations.