AZ-104
Deep Dive
Azure Monitor alerts notify you when conditions of interest occur on your resources — metric thresholds, state changes or specific events in logs. The AZ-104 exam evaluates the creation and configuration of alert rules, alert types and action groups.
Contents
An Alert Rule continuously monitors data and creates an alert when defined conditions are met. It consists of: Scope (what to monitor), Condition (when to fire), Actions (what to do) and Alert Details (how it's named and documented).
Parts of an Alert Rule
Scope
Which resource(s) to monitor. It can be a specific resource, a resource group, or an entire subscription. For log alerts: the Log Analytics Workspace.
Condition (Signal + Logic)
Which signal to monitor (metric, log, activity log, health) and under what condition to fire (threshold, time window, operator).
Actions
What to do when it fires: Action Group with notifications and/or automations.
Alert Details
Name, description, severity (0-4) and whether the alert is created enabled or disabled.
Alert states
Metric Alerts
Based on Azure Monitor metric values. Frequent evaluation (every minute). Low latency.
Log Search Alerts
Based on results of KQL queries in Log Analytics. Higher latency (minimum 1 minute, typically 5-15 min). For complex patterns.
Activity Log Alerts
Based on Activity Log events (operations on resources). For detecting configuration changes or service events.
Service Health Alerts
Notify of incidents, planned maintenance and health advisories for Azure services affecting your subscription/region.
| Level | Name | Description | Example |
|---|---|---|---|
| Sev 0 | Critical | Service down — immediate impact on production | VM down, database unreachable |
| Sev 1 | Error | Serious problem requiring urgent attention | CPU >95% sustained, disk >90% |
| Sev 2 | Warning | Situation that could turn into an error | CPU >80%, high DB connections |
| Sev 3 | Informational | Informational event — no immediate impact | Start of planned maintenance |
| Sev 4 | Verbose | Detailed information for diagnostics | Debug logs, tracing events |
Best practices
Action group limits
• Max 5 action groups per alert rule
• Max 1000 emails per hour (rate limiting)
• SMS: 1 per 5 minutes per phone number
• Voice: 1 per 5 minutes per number
• Webhook: automatic retries on failure (exponential backoff)
Alert Processing Rules (formerly called Action Rules) let you modify the behavior of already-fired alerts: suppress notifications during maintenance windows, add additional action groups or filter which alerts receive which actions.
Suppression for maintenance
Silences all alerts for certain resources during a scheduled window. E.g. silencing CPU alerts during OS updates from 00:00-04:00.
Add action group
Adds an additional action group to alerts meeting certain criteria, without modifying existing alert rules. Useful for notifying multiple teams.
Assign owner
Automatically assigns alerts to a team or person based on the resource, severity or affected resource group.
Smart Groups automatically group related alerts using ML, reducing alert noise. Instead of receiving 50 individual alerts from different VMs during an incident, you receive 1 Smart Group with all of them related.
Did you get this topic?
Test what you just learned
A team wants to receive an alert when the CPU of any VM in a subscription exceeds 90% for more than 5 consecutive minutes. Which alert type and configuration is most efficient?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.