Monitor and Maintain

This domain is the smallest on the exam at 10–15% (tied with no other domain for last; the two largest, Identity and Governance and Deploy and Manage Azure Compute Resources, sit at 20–25%), but its questions are high-yield because every one turns on a crisp either/or you can memorize. It splits into two pillars. The first is observability: Azure Monitor, the platform that collects, analyzes, and acts on telemetry: metrics and logs going in, and Metrics Explorer, Log Analytics (queried with Kusto Query Language, KQL), alerts, Insights, and Network Watcher coming out. The second is resilience: keeping a workload's data and its availability protected against deletion, corruption, or a regional outage, delivered by Azure Backup and Azure Site Recovery (ASR). Settle which pillar a stem is in first, because the tooling never crosses over: you do not back up a VM with a metric alert, and you do not diagnose a blocked packet with a Recovery Services vault.

Azure Monitor keeps telemetry as exactly two data types, and the split is the load-bearing idea of the whole monitoring objective. Metrics are numeric values sampled at regular intervals into a time-series database: lightweight, near-real-time, read in Metrics Explorer, and the basis for fast metric alerts. Logs are richer timestamped table rows held in a Log Analytics workspace and queried with KQL, and they are what a log search alert evaluates. Two sources cost nothing to collect: platform metrics and the activity log (subscription control-plane events: who did what) arrive automatically, but resource logs (a service's detailed per-operation logs) produce nothing until you create a diagnostic setting, which both starts that collection and routes any source to a durable destination chosen by intent: Log Analytics to query, a Storage account to archive cheaply, or Event Hubs to stream to an external SIEM. So 'a number trending over time' wants a metric, 'event-level detail' wants a log, and 'my detailed logs are missing' almost always means no diagnostic setting was created.

Across all three signal types (metric, log search, and activity-log; Resource Health and Service Health alerts are themselves activity-log alerts) the structure is identical: an alert rule binds a target, a signal-and-condition, and an action group. The action group is the reusable bundle of notifications (email, SMS, push, voice) and actions (webhook, Azure Function, Logic App, ITSM, automation runbook), kept separate so one bundle serves many rules and the on-call list changes in one place. To silence noise during planned maintenance or attach an action group to many alerts by filter, you add an alert processing rule on top of fired alerts rather than disabling the rules: suppression keeps the rules evaluating and lifts on schedule. Above the raw data sit two convenience layers worth distinguishing: Azure Monitor Insights are curated, ready-made views for a resource type (VM, Storage, Network, Container Insights) that tell you a resource is unhealthy, while Azure Network Watcher is the separate regional toolkit (IP flow verify, Next hop, Connection Monitor) that tells you why IaaS traffic can't get there.

Azure Backup and Azure Site Recovery are the two halves of a business-continuity and disaster-recovery (BCDR) strategy, and the exam leans hard on telling them apart. Azure Backup takes periodic point-in-time copies of data into a vault so you can restore a known-good version after deletion, corruption, or ransomware: its recovery point is intentionally hours or days old, and the vault type follows the workload (a Recovery Services vault for classic workloads such as Azure VMs, Azure Files, and on-premises files via the MARS agent; a Backup vault for newer datasources such as blobs and managed disks). A backup policy is just a schedule plus retention, with Azure VM retention following the grandfather-father-son (GFS) pattern up to 99 years. Site Recovery instead continuously replicates a running VM's disks to a second region, so on a primary failure you fail over and bring the workload up there within minutes, losing only seconds of data: recovery point objective (RPO, how much data you can lose) measured in seconds against Backup's hours. So 'get deleted or corrupted data back' is Backup; 'survive a whole-region outage with the app online' is Site Recovery.

Resilience is not monitored by a separate stack: it reports and alerts through the observability pillar, which is why this single domain houses both. Backup reports (cross-vault trends such as storage consumed, job success rates, and policy adherence) are rendered as Azure workbooks powered by a Log Analytics workspace, so each vault must have a diagnostic setting sending its data there first: an empty backup report almost always means that diagnostic setting is missing. The two are split by purpose: a report is for after-the-fact trend analysis, never real-time. For immediate notification the moment a backup or restore fails, you use an Azure Monitor alert routed to an action group (email, SMS, ITSM, webhook), the exact rule-plus-action-group structure from the observability pillar. So 'notify me when a backup fails' is an alert, not a report, and 'my backup report is empty' is a missing diagnostic setting, not a backup problem.