Chapter 5

Monitor and Maintain Azure Resources

Microsoft Azure Administrator (AZ-104) Study GuideBased on the Microsoft AZ-104 exam objectives

You can build a perfect Azure environment and still fail as an administrator if you cannot see what is happening inside it. Monitoring is how you detect a full disk before it crashes a database, how you prove to an auditor that a deleted VM can be restored, and how you answer the 2 a.m. question: "Is it the network, or is it the application?" This chapter covers the tools Azure gives you to watch resources, collect and query telemetry, get alerted before users complain, diagnose network problems, back up data, recover from disasters, and keep operating systems patched.

Azure Monitor: Metrics vs Logs

Azure Monitor is the umbrella platform for all monitoring data in Azure. Everything it collects falls into two fundamentally different data types, and the exam loves to test whether you know which is which: metrics and logs.

Metrics are lightweight numerical values captured at regular intervals — things like CPU percentage, disk queue depth, or incoming network bytes. They are near-real-time (typically available within a minute or two), structured, and cheap to store. Azure collects platform metrics for most resources automatically with no configuration. Metric data is retained for 93 days. Because metrics are just numbers over time, they are ideal for dashboards and for alerting ("tell me when CPU exceeds 85% for 10 minutes") but useless for answering "why" — a CPU spike metric cannot tell you which process caused it.

Logs are rich, detailed records of events — every entry is a row with many columns (timestamp, computer name, event ID, message text, and so on). Logs live in Log Analytics workspaces and are queried with KQL (covered in the next section). Logs answer "why" questions: which user deleted the resource group, which process consumed the memory, which IP addresses hit the firewall. The tradeoff is cost and latency: logs take a few minutes to become queryable, and you pay for ingestion and retention. The first 31 days of ingested data per workspace per month are free; interactive retention can be extended (up to two years on Analytics tables), and older data can be moved to cheap archive storage for compliance.

Data Collection: DCRs and the Azure Monitor Agent

Metrics flow automatically, but logs and guest-OS performance data must be collected deliberately. Modern Azure does this with two linked pieces: the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs).

The AMA is a lightweight agent installed on Azure VMs and Azure Arc-enabled servers. A Data Collection Rule defines what to collect (which performance counters, which Windows event logs or syslog facilities), how to transform it, and where to send it (which Log Analytics workspace). One DCR can target many machines, so you define the rule once and associate it with every VM that needs it — far cleaner than configuring agents one by one.

VM Insights and Container Insights

Raw counters are hard to read at scale, so Azure Monitor provides curated experiences on top of the collected data. VM insights gives you per-VM performance views (CPU, memory, disk, network trends), a process-level breakdown showing exactly which processes are consuming resources, and a dependency map showing which machines and processes talk to each other — invaluable when "the app is slow" and nobody knows which tier is the bottleneck. It requires the AMA and a DCR.

Container insights does the same job for Azure Kubernetes Service (AKS): node and pod CPU/memory utilization, container logs, and cluster health. If the question involves monitoring AKS workloads, Container insights is the answer.

Diagnostic Settings: Routing Platform Data

Many Azure resources (key vaults, storage accounts, network security groups, Azure SQL) emit resource logs — records of operations performed against the resource itself, such as key vault secret reads or storage authentication failures. These logs are not stored anywhere by default. You create a diagnostic setting on the resource to route them to one or more of three destinations:

1. A Log Analytics workspace — for querying with KQL and building log alerts.
2. A Storage account — for cheap long-term archival and compliance.
3. An Event Hub — for streaming to SIEMs or third-party analytics tools.

Worked Scenario: The Mystery CPU Spike

It is Tuesday morning. Users report the order-processing app is sluggish. The on-call admin opens Azure Monitor.

Step 1 — Metrics for "what is happening." The VM's Percentage CPU metric shows sustained 95% usage starting at 6:40 a.m. Metrics confirm the symptom and its start time, but not the cause.

Step 2 — Logs for "why." In the Log Analytics workspace, VM insights data shows a single process — a runaway reporting job — consuming 80% of CPU. The dependency map shows it started right after a scheduled task fired at 6:40.

Step 3 — Fix and prevent. The admin kills the job and creates a metric alert: if Percentage CPU exceeds 85% for 10 minutes, notify the on-call action group. Next time, the team hears about it before users do.

This is the core monitoring workflow the exam expects you to internalize: metrics detect, logs explain, alerts notify.

KQL Essentials for Azure Admins

The Kusto Query Language (KQL) is how you interrogate log data in Log Analytics. You do not need to be a KQL expert for AZ-104, but you must read basic queries and predict what they return. Every query starts with a table, then pipes (|) filter and shape the data.

The Operators You Must Know

• where — filters rows. where TimeGenerated > ago(1h) keeps only the last hour. ago() is the standard way to express relative time.
• project — picks which columns to show. project Computer, EventID drops everything else.
• summarize — aggregates. summarize count() by Computer counts rows per computer. Think "GROUP BY" in SQL.
• count — returns a single row with the total number of rows. Handy for "how many events matched?"
• take — returns the first N rows (take 10). Fast way to sample.
• render — visualizes. render timechart turns time-series results into a graph for dashboards and workbooks.

Time filtering almost always uses the TimeGenerated column: where TimeGenerated > ago(24h). The exam frequently hides the answer in the time filter — a query asking "in the last 30 minutes" with ago(24h) is sloppy but a query with ago(30m) is precise.

String matching has one critical subtlety: contains is case-insensitive, while == is case-sensitive. Searching where Message contains "error" matches "Error", "ERROR", and "error". But where Level == "error" matches only the exact lowercase string — "Error" would not match. (The case-sensitive variant of contains is contains_cs, which you will rarely need.)

Annotated Query Examples

Example 1 — Count failed logons in the last hour:

SecurityEvent
| where TimeGenerated > ago(1h)   // only the last 60 minutes
| where EventID == 4625            // 4625 = failed logon on Windows
| summarize FailedLogons = count() by Computer  // group by machine
| project Computer, FailedLogons  // show just these two columns
| render columnchart               // bar chart per computer

Reading it top to bottom: take the SecurityEvent table, keep recent rows, keep only failed logons, count them per computer, display two columns as a bar chart. A spike on one computer suggests a brute-force attack or a broken service account.

Example 2 — Find errors mentioning a service, any casing:

Event
| where TimeGenerated > ago(24h)
| where EventLog == "Application"
| where RenderedDescription contains "paymentservice"  // case-insensitive!
| project TimeGenerated, Computer, RenderedDescription
| take 20

contains catches "PaymentService", "paymentservice", and "PAYMENTSERVICE". Using == here would silently miss most rows — exactly the trap the exam sets.

Example 3 — Average CPU per VM over the last 6 hours, as a time chart:

Perf
| where TimeGenerated > ago(6h)
| where CounterName == "% Processor Time"  // exact match, case matters
| summarize AvgCPU = avg(CounterValue) by Computer, bin(TimeGenerated, 15m)
| render timechart

bin(TimeGenerated, 15m) buckets time into 15-minute windows so the chart is readable. Note == with the exact counter name — copy it precisely or you get zero rows.

Example 4 — How many heartbeat failures in the last day?

Heartbeat
| where TimeGenerated > ago(1d)
| where ComputerEnvironment == "Azure"
| count

The count operator collapses everything to one number — perfect for a quick "is anything down?" check or a log-alert query (more on alerts next).

Alerts: Turning Signals into Action

Monitoring without alerting is just expensive history. An alert rule watches a signal and notifies someone when a condition is met. Every alert rule has three parts:

1. Signal — what is being watched: a metric (CPU percentage), a log query (failed logons per hour), or the activity log (someone deleted a resource).
2. Condition — the logic: threshold ("greater than 85"), evaluation period ("over the last 10 minutes"), and how often to evaluate.
3. Action group — who gets told and what happens: the reusable notification package triggered when the rule fires.

Metric alerts evaluate numerical time series frequently — as often as every minute — so they fire within minutes of a problem. They support static thresholds ("CPU > 85%") and dynamic thresholds (machine-learning baselines that adapt to normal patterns, great for workloads with daily cycles). Dynamic thresholds are worth a closer look because the exam likes them: instead of you guessing that "85%" is the right number, Azure learns the metric's normal rhythm over past weeks and alerts when the value deviates significantly — high or low — from the learned baseline. This shines for metrics with predictable patterns, like a web server whose traffic peaks every weekday at noon; a static threshold would either miss the anomaly or page you every lunch hour. You can also scope one metric alert rule across many resources of the same type (all VMs in a resource group, for example) using dimensions to split alerts per instance, which keeps rule sprawl under control. Log alerts run a KQL query on a schedule (for example, every 15 minutes over the last 30 minutes of data) and fire when the result count crosses a threshold. Log alerts are more flexible but slower — expect several minutes of latency.

Severity and State

Every alert carries a severity from Sev 0 (critical) down to Sev 4 (verbose):

• Sev 0 — Critical: service is down or data loss is possible. Wake someone up.
• Sev 1 — Error: major functionality impaired.
• Sev 2 — Warning: degrading, investigate soon.
• Sev 3 — Informational: worth knowing, no action required yet.
• Sev 4 — Verbose: diagnostic detail.

Alerts also move through states: New (just fired, nobody has looked), Acknowledged (someone owns it and is working on it), Closed (resolved — either the condition cleared or a human closed it).

Action Groups and Alert Processing Rules

An action group is a named collection of notifications and automated responses: email and SMS to on-call staff, push notifications to the Azure mobile app, voice calls, plus actions like calling a webhook, triggering a Logic App, running an Automation runbook, or creating an ITSM ticket. Because action groups are reusable, you define "Notify the Platform Team" once and attach it to fifty alert rules. Note that SMS and voice notifications are rate-limited — do not design a system that pages the same phone every minute.

Alert processing rules sit above individual alert rules and modify behavior across scopes and schedules. Their most common use is suppression: during a Sunday 2–4 a.m. patching window, you know CPU and disk alerts will fire, so a processing rule suppresses notifications for that window (the alerts still fire and are recorded — they just do not page anyone). Processing rules can also add action groups or escalate severity for specific scopes.

Worked Scenario: Taming the Patch-Window Alert Storm

Every Sunday at 2 a.m., the patching automation reboots 40 VMs. Every Sunday at 2:05 a.m., the on-call phone explodes with 120 alerts.

Step 1 — Identify the pattern. The alerts are legitimate signals (VMs really are unavailable) but expected: they always occur during the maintenance window and always clear by 4 a.m.

Step 2 — Suppress, do not disable. Disabling the alert rules would leave a gap if patching overruns. Instead, create an alert processing rule scoped to the VM resource group, scheduled Sundays 2:00–4:30 a.m., with the action suppress notifications. The alerts still fire and are logged (auditors stay happy), but nobody gets paged.

Step 3 — Keep a safety net. Add a second rule: if any VM is still unavailable at 5 a.m. (after the window), fire a Sev 1 to the on-call group. Expected noise is silenced; genuine failures still surface.

Network Watcher: Proving What the Network Does

When connectivity breaks, guessing wastes hours. Network Watcher provides diagnostic tools that test the network's actual behavior rather than its intended configuration. It operates per region, and features like NSG flow logs require it to be present in the region where your VNets live.

• IP flow verify — answers "would this packet be allowed?" You supply the 5-tuple (source and destination IP, source and destination port, protocol) and the NIC, and it tells you whether the effective NSG rules allow or deny it, and which rule decided. This is the fastest way to settle "is the NSG blocking it?"
• Effective security rules — shows the complete merged rule set applied to a VM or NIC (subnet NSG plus NIC NSG), so you can read the actual policy instead of hunting through two separate NSG blades.
• Next hop — shows where Azure would route a packet from a VM toward a destination: Internet, VNet peering, VPN gateway, virtual appliance, or none (black hole). Settles "is there even a route?"
• Packet capture — captures traffic on a VM and writes it to a storage account for analysis in Wireshark. Use it when you need to see the actual packets, not just the policy decision.
• Connection troubleshoot — runs an end-to-end TCP connectivity check from a VM to another VM, an FQDN, or a public IP, reporting each hop and where the failure occurs.

NSG Flow Logs vs Traffic Analytics

NSG flow logs record every allowed and denied flow through an NSG (source/destination, ports, protocol, decision) as JSON files in a storage account. They are the raw evidence — perfect for "who tried to reach this port last night?" but painful to read at scale.

Traffic Analytics ingests those flow logs into a Log Analytics workspace and turns them into visualizations and insights: top talkers, geographic traffic distribution, malicious traffic patterns, and under/over-utilized NSG rules. Think of it as the relationship: flow logs are the data, Traffic Analytics is the analysis. Traffic Analytics requires a Log Analytics workspace; flow logs require only a storage account (and Network Watcher in the region).

Worked Scenario: The App Server That Cannot Reach the Database

A web server in subnet Web cannot connect to SQL on port 1433 in subnet Data. The app team blames the network; the network team blames the app.

Step 1 — IP flow verify. Test TCP from the web VM's IP to the SQL IP on port 1433. Result: Denied, by an NSG rule named Deny-DataSubnet-Inbound with priority 200. Mystery solved in 60 seconds — no packet capture needed.

Step 2 — Effective security rules. Viewing the Data subnet's effective rules shows the deny rule sits above the allow rule for 1433 — a priority-ordering mistake from last week's change.

Step 3 — Fix and verify. Move the allow rule to a lower priority number (higher precedence), then re-run IP flow verify: Allowed. The app connects. Total time: under 10 minutes, with evidence at every step instead of opinions.

Backup: Protecting Data

Azure Backup protects your data without backup servers or tape libraries. The first decision is where the backup lives, because Azure has two vault types and the exam tests the split relentlessly.

A Recovery Services vault (RSV) protects classic workloads: Azure VMs, on-premises servers (via the MARS agent, DPM, or MABS), Azure file shares, SQL Server running in Azure VMs, and SAP HANA in Azure VMs. A Backup vault is the newer vault type for newer workloads: Azure managed disks (disk backup), Azure Blobs (operational backup), and Azure Database for PostgreSQL.

Policies, Retention, and Instant Restore

Backups run on a backup policy: schedule (how often) plus retention (how long each recovery point is kept). The built-in DefaultPolicy backs up once daily and retains each recovery point for 30 days. For Azure VMs, the first snapshot is also kept as an instant restore snapshot for 2 days, so restores from the last 48 hours complete in minutes without transferring data out of the vault.

Soft Delete and Immutable Vaults

Two features protect backups from the two scariest scenarios: accidents and ransomware.

Soft delete retains backup data for 14 days after a backup item is deleted. If an attacker (or a tired admin) deletes the backups before encrypting your VMs, you can still recover them within the 14-day window. It is enabled by default on new vaults.

Immutable vaults go further: once enabled, recovery points cannot be deleted by anyone — not even a subscription owner — until their retention period expires. This is your answer to "how do we guarantee backups survive a compromised admin account?"

The MARS Agent and File Recovery

The Microsoft Azure Recovery Services (MARS) agent backs up on-premises Windows servers and individual files/folders directly to an RSV — no System Center infrastructure required. Its key limit: a maximum of 3 scheduled backups per day. From any recovery point you can do item-level (file/folder) recovery: download a small executable, mount the recovery point locally, and copy out just the files you need instead of restoring the whole machine.

Workload Specifics Worth Knowing

• Azure VMs: application-consistent backups use the VSS snapshot (Windows) or fsfreeze (Linux) to quiesce the OS; without it you get crash-consistent backups.
• SQL Server in Azure VMs: workload-aware backup with log backups enabling point-in-time restore — you can restore to any second, not just to nightly backup times.
• Azure Files: snapshot-based backup of file shares, with item-level file restore.
• Cross-region restore: for geo-redundant vaults, you can restore a VM's backup in the paired secondary region even if the primary region is down.

Backup Center: One Pane of Glass

When backups span dozens of vaults, subscriptions, and workload types, Backup Center gives you a single dashboard: which backup items are healthy, which jobs failed last night, whether any vault lacks soft delete or immutability, and compliance views showing which resources are not protected at all. For the exam, remember it as the centralized management and governance view for all Azure Backup activity — if a question asks "how do you see backup compliance across the estate?", the answer is Backup Center, not opening each vault.

Site Recovery: Business Continuity

Backup protects data; Azure Site Recovery (ASR) protects operations — it keeps copies of your VMs replicating to a secondary region so you can fail over the whole workload when a region has problems. Replication is continuous, with a Recovery Point Objective (RPO) typically measured in minutes — that is the maximum data you stand to lose.

Each protected machine runs the Mobility service, a lightweight agent that captures disk writes and replicates them to the target region. (For Hyper-V and VMware/physical sources there are additional components; for Azure-to-Azure replication the Mobility service plus the Site Recovery infrastructure is the core.)

The Three Failovers

This is pure exam territory — know all three and how they differ:

• Test failover — spins up the replicated VMs on an isolated test network. Production is untouched and replication continues. Use it for DR drills and audits. Zero risk, zero impact.
• Planned failover — for expected outages (datacenter maintenance, a planned region move). The source VMs are shut down gracefully first, final changes replicate, then the secondary VMs start. Zero data loss because the source was cleanly stopped.
• Unplanned failover — for real disasters. The primary is assumed gone, so ASR brings up the secondary from the latest available recovery point. Some data loss is possible (up to the RPO), but the business is running again.

Failback, Recovery Plans, and Recovery Points

Failing over is only half the story. Failback returns operations to the primary region: you re-protect (reverse the replication direction so the secondary now replicates back to the primary), then fail over again. Skipping re-protect is a classic exam trap — without it, you have no protection during the return trip.

Recovery plans group machines into an ordered runbook: bring up domain controllers first, then databases, then app servers, with optional scripts and manual approval steps between tiers. If a question describes multi-tier startup ordering, the answer is a recovery plan.

Recovery points come in two flavors: crash-consistent (the disk state as if the power cord were pulled — fine for most VMs) and app-consistent (the application was quiesced via VSS before the snapshot, so SQL/AD databases are transactionally clean). For database workloads, always prefer app-consistent points.

Update Management and Maintenance

The last piece of "maintain" is keeping operating systems patched. Azure Update Manager (the unified Update Management Center experience) assesses and installs OS updates on Azure VMs and Azure Arc-enabled servers from one place. The workflow has three parts. First, assess: on demand or on a recurring schedule, Update Manager scans machines and reports which updates each one is missing, flagging critical and security patches. Second, deploy: install updates immediately for an emergency patch, or create a schedule — for example, "install critical and security updates on all production VMs every Sunday at 2 a.m." — and let Azure handle the rollout, including pre- and post-patch scripts if you need services stopped and restarted cleanly. Third, verify: the deployment status view shows per-machine results, so a failed patch on one VM does not go unnoticed. This pairs naturally with the alert-suppression window from the earlier scenario: the same Sunday 2 a.m. schedule drives both the patching and the alert processing rule that silences the expected reboot noise.

Separately, maintenance configurations let you control when Azure itself is allowed to perform platform maintenance on your resources — for example, defining a recurring window for host updates on dedicated hosts, or scheduling guest patch orchestration so Azure-managed patching of VMs happens inside your approved change window. The idea is the same in both cases: patches and maintenance happen on your schedule, not as a surprise. On the exam, if the scenario is about your OS patching, think Update Manager; if it is about Azure's platform maintenance timing, think maintenance configurations.

End-of-Chapter Test

1. Your compliance team requires 18 months of queryable security event history. Platform metrics are already collected. Which approach meets the requirement?

A) Rely on platform metrics, which are retained for 18 months B) Route the events to a Log Analytics workspace and configure extended retention C) Enable NSG flow logs to a storage account D) Create a metric alert with an 18-month evaluation period

2. An administrator writes the following KQL query to find all logon failures regardless of how the word "failed" is capitalized:

SecurityEvent
| where TimeGenerated > ago(1h)
| where AccountType == "User"
| where Activity contains "failed"

Which statement about this query is true?

A) It will miss "FAILED" because contains is case-sensitive B) It will match "failed", "Failed", and "FAILED" because contains is case-insensitive C) It will fail because == cannot be used with string columns D) It will return zero rows because Activity is not a valid column

3. You need to archive key vault audit logs for 7 years as cheaply as possible. The security team only needs to query them in rare investigations. Which diagnostic setting destination should you choose?

A) Log Analytics workspace B) Event Hubs C) Storage account D) Azure Monitor managed service for Prometheus

4. A critical production database goes offline at 3 a.m. Which alert severity should the alert rule use so the on-call engineer is paged immediately?

A) Sev 4 B) Sev 2 C) Sev 0 D) Sev 3

5. You must back up Azure managed disks with operational backup so developers can restore individual files. Which vault type do you need?

A) Recovery Services vault B) Backup vault C) Key vault D) Log Analytics workspace

6. An on-premises file server must be backed up to Azure four times per day using the MARS agent. What should you tell the stakeholder?

A) The MARS agent supports a maximum of 3 scheduled backups per day; adjust the requirement B) Install four MARS agents on the server, one per backup C) The MARS agent supports unlimited daily backups D) Use Azure Site Recovery instead, which backs up hourly

7. Your primary Azure region suffers an extended outage. You fail over production VMs to the secondary region, accepting that a few minutes of data may be lost. Which failover type did you perform?

A) Test failover B) Planned failover C) Unplanned failover D) Recovery plan failover

8. A VM in subnet A cannot reach a VM in subnet B. You want to determine which NSG rule is blocking the traffic without capturing packets. Which Network Watcher tool should you use first?

A) Packet capture B) Next hop C) IP flow verify D) Connection troubleshoot

9. You are designing monitoring for 200 new Azure VMs. The security team requires centralized collection of Windows event logs using the current Microsoft-recommended approach. What should you deploy?

A) The Log Analytics agent (MMA) on each VM B) The Azure Monitor Agent with a Data Collection Rule C) A diagnostic setting on each VM D) Container insights

10. An attacker deletes a VM's backups from the Recovery Services vault on Monday. On Thursday, you discover the deletion. Can you still recover the backup data, and why?

A) No — deleted backups are unrecoverable immediately B) Yes — soft delete retains the backup data for 14 days by default C) Yes — the vault's DefaultPolicy keeps deleted items for 30 days D) No — unless an immutable vault was configured in advance

---

Answer Key

1. B — Metrics are retained only 93 days and cannot answer "why" questions; 18 months of queryable event history requires logs in a Log Analytics workspace with extended retention.

2. B — contains is case-insensitive in KQL, so it matches all capitalizations; == is the case-sensitive operator.

3. C — A storage account is the cheapest destination for long-term archival; Log Analytics is for active querying and Event Hubs is for streaming.

4. C — Sev 0 (critical) is the highest severity and the correct choice for paging on a production outage; Sev 4 is the lowest.

5. B — Managed disk backup is a Backup vault workload; Recovery Services vaults handle VMs, on-premises servers, file shares, and SQL/SAP HANA in Azure VMs.

6. A — The MARS agent allows a maximum of 3 scheduled backups per day, so the four-times-daily requirement cannot be met as stated.

7. C — Unplanned failover is used for real disasters from the latest recovery point, accepting possible data loss up to the RPO; planned failover has zero data loss and test failover has no production impact.

8. C — IP flow verify tests a packet's 5-tuple against effective NSG rules and names the blocking rule; packet capture is for deeper analysis, next hop checks routing, and connection troubleshoot tests end-to-end TCP.

9. B — The Azure Monitor Agent with a Data Collection Rule is the current approach; the MMA/Log Analytics agent is retired, diagnostic settings do not apply to VM guest logs this way, and Container insights targets AKS.

10. B — Soft delete is enabled by default and retains deleted backup data for 14 days, so Thursday recovery is possible; an immutable vault would additionally have prevented the deletion entirely.