Monitor and maintain Azure resources Study Guide — AZ-104

Monitor and Maintain Azure Resources

Microsoft weights this domain at 10–15% of the AZ-104 exam, the smallest share. It tests your ability to implement observability, alerting, backup, and disaster recovery for Azure resources. Expect scenario-based questions that require you to choose the correct Azure Monitor component, configure the right alert type, select an appropriate backup policy, or determine which Network Watcher tool solves a given connectivity problem. You must know exact service names, configuration steps, and the distinctions between closely related features.

Azure Monitor Metrics, Log Analytics Workspaces, and KQL Basics

Azure Monitor Overview

Azure Monitor is the unified monitoring platform for Azure. It collects two fundamental data types:

• Metrics: Numerical time-series data collected at regular intervals (default: 1-minute granularity). Stored in the Azure Monitor Metrics store (a time-series database). Retained for 93 days by default.
• Logs: Structured or unstructured text data stored in a Log Analytics workspace (backed by Azure Data Explorer). Retained for 30 days by default; configurable up to 730 days (2 years) in the workspace, or up to 7 years with long-term retention archival.

Log Analytics Workspace

A Log Analytics workspace is the central repository for log data from Azure resources, on-premises systems, and other clouds. Key facts:

• One workspace can serve multiple subscriptions and resource groups.
• Data is ingested via diagnostic settings, agents (Azure Monitor Agent / AMA), or the Log Analytics workspace Data Collection Rules (DCRs).
• The legacy MMA (Microsoft Monitoring Agent) and OMS agent are being retired; AMA is the current standard.
• Access control: workspace-centric (workspace permissions apply to all tables) or resource-centric (users see only data from resources they have RBAC access to).

KQL Basics

KQL (Kusto Query Language) is the query language for Log Analytics. You are not expected to write complex queries on the exam, but you must recognize valid syntax and understand the core operators:

• Heartbeat | where Computer == "myVM" | summarize count() by bin(TimeGenerated, 1h) — filters and aggregates agent heartbeat logs.
• Key operators: where, project, summarize, extend, order by, take, join, union.
• Table names are case-sensitive: AzureActivity, Heartbeat, Perf, SecurityEvent, AzureDiagnostics.

Common Traps

• Metrics are not stored in a Log Analytics workspace — they go to the Metrics store. You must explicitly configure a diagnostic setting to route metrics to a workspace.
• Increasing metric retention beyond 93 days requires routing to a storage account or Log Analytics workspace via diagnostic settings.
• AMA replaces both MMA and OMS agent — do not choose MMA for new deployments.
• Log ingestion has a ~5-minute lag; metrics are near real-time. Do not recommend logs for sub-minute alerting.

Alert Rules, Action Groups, and Alert Processing Rules

Alert Rules

An alert rule monitors a signal and fires when a condition is met. Three main alert types:

Key alert rule components:

• Scope: The resource(s) being monitored.
• Condition: The signal type and threshold.
• Action group: What happens when the alert fires.
• Alert rule severity: 0 (Critical) to 4 (Verbose).
• Stateful vs. stateless: Metric alerts are stateful by default (auto-resolve when condition clears); log search alerts default to stateless.

Action Groups

An action group defines the notifications and automated actions triggered when an alert fires. One action group can be shared across multiple alert rules.

Alert Processing Rules

Alert processing rules (formerly "action rules") are applied after an alert fires. They operate on fired alerts — not on the alert rule itself. Use them to:

• Suppress notifications during a maintenance window.
• Add or remove action groups from matching alerts.
• Apply to a scope (subscription, resource group, or resource) and a filter (alert severity, monitor service, etc.).

Key distinction: Alert rules define when to fire. Alert processing rules define what to do with fired alerts.

Worked Scenario: A team wants to stop receiving alert notifications every Saturday from 10:00–14:00 for planned maintenance. The correct solution is to create an alert processing rule with a recurring suppression schedule — not to disable the alert rule (which would stop monitoring entirely).

Common Traps

• Action groups are not alert rules — they are reusable notification/action configurations attached to alert rules.
• An alert processing rule does not prevent alert evaluation; the alert still fires and is visible in the portal — only notifications/actions are suppressed.
• Activity log alerts fire on events (not metrics), so they are inherently near real-time and do not require a frequency setting.
• You can attach multiple action groups to a single alert rule.
• Dynamic thresholds in metric alerts use ML to learn baseline behavior — select this when you cannot specify a fixed threshold.