Use Azure Monitor, Insights, and Alerting for AZ-104
Learn the metrics, logs, alerting, and insights behaviors that matter most for AZ-104 operational scenarios.
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
| Need | Strongest first choice | Why |
|---|---|---|
| Fast threshold on a numeric signal | Metric alert | Lightweight and direct |
| Correlate events or investigate richer history | Logs in Log Analytics | Better for multi-step analysis |
| View curated resource health trends quickly | Azure Monitor Insights | Built for common resource-type visibility |
| Notify or automate when an alert fires | Action group | It handles the response path |
Telemetry map
| Signal type | Best use |
|---|---|
| Metrics | Fast numeric trends such as CPU, latency, or request count |
| Activity Log | Subscription-level control-plane events such as creates, deletes, and policy actions |
| Resource logs | Resource-specific operational detail sent through diagnostic settings |
| Insights | Ready-made views over common resources such as VMs and networks |
| Alert processing rules | Post-alert control over how notifications are routed or suppressed |
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
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.