Domain 5 of 5 · Chapter 1 of 2

Azure Monitor

Two data types and the collection pipeline

Azure stores every piece of telemetry as exactly one of two data types, and that single choice decides every tool, store, and query language you will touch in this objective. A number trending over time (CPU %, request count) is a metric; a record of which events happened, with detail, is a log. Get that fork right and a monitoring design (diagnostic settings, metric charts, Kusto queries, alerts, Network Watcher) assembles itself; get it wrong and you reach for the wrong tool every time.

Azure Monitor[1] is Microsoft's unified service for collecting, analyzing, and acting on telemetry from Azure (and hybrid) resources. Everything in this objective hangs off one distinction: Azure Monitor stores telemetry as exactly two data types, and which type you are holding determines every tool, store, and query language you touch.

Metrics vs logs: one model, two shapes

Think of both as timestamped telemetry; they differ only in shape and store.

  • Metrics are numeric values sampled at regular intervals (a value plus a timestamp) held in a time-series database[2]. They are lightweight and near-real-time, which is why they back charts and the fastest alerts. You read them in Metrics Explorer.
  • Logs are richer records organized into tables, held in a Log Analytics workspace[1]. Each row can carry many columns of event detail. You query them with Kusto Query Language (KQL) in Log Analytics.

The exam tell: a stem about a number trending over time (CPU %, IOPS, request count) is a metric; a stem about which events happened, with detail (who deleted the resource, every failed request) is a log.

The three sources and what each costs to turn on

Diagnostic settings can collect from three sources[3], and the load-bearing fact is which ones are free and automatic:

Source Collected automatically? What it is
Platform metrics[3] Yes, no configuration The resource's built-in numeric counters
Activity log[3] Yes, no configuration Subscription-level control-plane events: who did what to a resource
Resource logs[3] No, off by default The detailed per-operation logs a service emits (formerly 'diagnostic logs')

Platform metrics and the activity log are gathered with zero setup. Resource logs are not collected until you create a diagnostic setting. There is simply nothing to query otherwise. This is the single most common gap in a monitoring design.

The diagnostic setting is the router

A diagnostic setting[3] does two jobs: it starts collecting resource logs, and it routes any of the three sources to a destination so the data outlives its default window. Even though platform metrics and the activity log are already collected, you still need a diagnostic setting to send them somewhere durable (a workspace, an archive, or an external stream). You create one diagnostic setting per resource per destination-set, and each resource can have up to five diagnostic settings.

Platform metricsauto, no configActivity logauto, no configResource logsoff by defaultDiagnostic settingmax 5 per resourceLog Analytics workspacequery with KQLAzure Storage accountarchive, keep indefinitelyAzure Event Hubsstream to SIEMPartner solutionthird-party platform
Three sources flow through a diagnostic setting (max five per resource) to four destination types, each suited to a different job.

Choosing a diagnostic-setting destination

The four destinations[3] of a diagnostic setting are not interchangeable: each is built for one job, so you pick the destination that matches what you intend to do with the data. Building on the pipeline above, that intent is what this section maps out.

The four destinations, by intent

  • Log Analytics workspace[3]: the choice whenever you want to query and correlate. It is the only destination you can search with KQL, build workbooks over, and target with log alerts. Tables are created automatically the first time data arrives, so only the workspace itself must pre-exist.
  • Azure Storage account[3]: the cheap, keep-it-indefinitely archive for audit, compliance, or backup. Add an immutability policy when the records must be tamper-proof. Only standard storage accounts are supported as a destination; premium accounts are not.
  • Azure Event Hubs[3]: the way to stream telemetry out to an external system such as a non-Microsoft SIEM. Storage and Log Analytics hold data; only Event Hubs pushes a live stream to a third party.
  • Azure Monitor partner solution[3]: an integrated handoff to a partner observability platform.

The one-of-each rule, reconciled

A single diagnostic setting can send to several destinations, but no more than one of each type. That sounds like it contradicts 'you can send everywhere at once'; the reconciliation is that 'everywhere at once' means one of each kind in a single setting (one workspace + one storage account + one event hub). The moment you need two of the same kind (two Log Analytics workspaces, or two storage accounts) you create a second diagnostic setting, and remember the ceiling: five settings per resource[3].

Same-region and cost notes worth memorizing

For regional resources, a Storage account or Event Hub destination must be in the same region as the monitored resource. Two cost facts the exam likes: platform metrics are already in Metrics Explorer for free, so skip exporting them to a workspace unless you need them in KQL; and collect only the log categories you actually need, because a Log Analytics workspace bills per GB ingested.

# Route a resource's audit logs + all platform metrics to a Log Analytics workspace
az monitor diagnostic-settings create \
  --name KeyVault-Diagnostics \
  --resource <resource-id> \
  --logs    '[{"categoryGroup": "audit", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]' \
  --workspace <log-analytics-workspace-id>

The AllMetrics[3] category is how you opt platform metrics into a destination; for logs you either pick individual categories or a category group (audit or allLogs).

Interpreting metrics and querying logs (KQL)

A metric is pre-aggregated for speed, while a log is raw rows you shape yourself with a query — that single contrast is the unifying idea behind reading a metric chart correctly and writing a basic Kusto query. Building on metrics being numeric time series and logs living in a workspace, this section works both.

Reading a metric: aggregation and granularity

In Metrics Explorer[2] you pick a metric namespace (a category that groups related metrics), then a metric, then an aggregation, the statistic Azure computes over each time bucket. There are exactly five aggregation types[2]:

Aggregation Meaning
Sum Total of all values captured in the interval (a.k.a. Total)
Count Number of measurements (samples), ignores the values themselves
Average Average of the values; for most metrics this is Sum / Count
Min Smallest value in the interval
Max Largest value in the interval

A subtle, testable detail: Average is never pre-stored. It is always recalculated as Sum ÷ Count for the chosen grain, which is why Min and Max can reveal a spike that Average and Sum smooth away.

Time granularity (time grain) is the bucket size each plotted point aggregates. The minimum granularity is 1 minute[2]; coarser grains are computed from the stored 1-minute values. Widening the grain trades detail for noise reduction, usually what you want before wiring a metric to an alert, so a brief CPU blip doesn't page you but a sustained one does.

Dimensions are name-value pairs attached to a metric (for example, a per-VM or per-instance breakdown). In the chart you split by a dimension to see each value separately, or filter to show only some, the way you find which instance caused a spike in an aggregated line.

Querying logs with KQL

Logs in a Log Analytics workspace[1] are queried with Kusto Query Language. A KQL query starts from a table name and pipes (|) the rows through operators: where to filter, summarize to aggregate, project to choose columns, sort/top to order. The figure below traces that pipe chain on the example query in order, each | handing its filtered rows to the next operator:

// Count failed sign-ins per user in the last 24 hours, busiest first
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize Failures = count() by UserPrincipalName
| sort by Failures desc

Use logs (not metrics) when you need event-level detail, cross-resource correlation, or anything string-valued. One workspace can hold data from many resources across subscriptions and regions, which is exactly why a single log search alert can watch them all at once.

SigninLogstablewherefilter rowssummarizeaggregateprojectchoose columnssortorder result||||
A KQL query is a pipe chain: a table feeds where, summarize, project, then sort, each operator passing its rows to the next.

Alerts, action groups, and alert processing rules

An alert rule[4] binds three things (a target resource, a signal and condition, and an action group), and an alert processing rule layers on top to mute or reroute the alerts that fire. Building on a signal you can already produce (a metric, a KQL result, or an activity-log event), that model is how you assemble an alert and control its noise at scale. The figure traces that path: a target plus a signal/condition make an alert rule, the rule fires an alert, an optional alert processing rule intercepts it, and the action group runs the notifications and actions.

The three alert-rule types, by signal

Rule type Evaluates Use when
Metric alert[4] A metric crossing a static or dynamic threshold Fast, numeric conditions (CPU > 90%)
Log search alert[4] A KQL query returning rows at a set frequency Event detail / cross-resource queries
Activity log alert[4] A new activity-log event matching a filter Control-plane events (a VM was deleted)

Resource Health and Service Health alerts are themselves activity log alerts[4]; recognizing that mapping is a common exam point.

Action groups: the reusable 'what to do'

An action group[4] is a named, reusable bundle of notifications (email, SMS, push, voice) and actions (webhook, secure webhook, Azure Function, Logic App, ITSM, automation runbook, Event Hub). Keep it separate from the rule on purpose: one action group (say, the on-call distribution list) is referenced by dozens of alert rules, so you maintain the recipients in one place.

Alert state and severity

Each fired alert carries two independent states. The monitor condition is system-set: fired while the condition holds, then resolved once it clears (a stateful metric alert resolves after the condition isn't met for three consecutive checks[4]). The user response is yours to set (New, Acknowledged, or Closed) and never changes on its own. Alert instances are stored for 30 days[4]. Severity runs Sev 0 (critical) to Sev 4 (verbose).

Alert processing rules: mute and reroute at scale

An alert processing rule[4] modifies alerts as they fire, by filter and on a schedule, without touching any alert rule. Its two headline jobs: suppress notifications (silence everything in a resource group during a planned maintenance window, the rules keep evaluating, only the noise is muted, and suppression lifts automatically) and add an action group to many alerts at once. The distinction the exam wants: don't disable or delete the alert rule to go quiet for maintenance, write an alert processing rule that suppresses. To create any alert rule you need Monitoring Contributor (read on the target, write on the rule's resource group); Monitoring Reader can view but not create.

Target resourceSignal + conditionmetric / log / activityAlert rulebinds the threeAlert processingrulesuppress / reroutefires alertAction groupnotifications + actionsif not muted
Target plus signal/condition make an alert rule; it fires an alert that an alert processing rule may mute or reroute before the action group runs.

Insights and Azure Network Watcher

Insights pre-build the view of a resource type, while Network Watcher diagnoses why traffic does or doesn't flow — that split is the choice between a ready-made monitoring page and the network-path diagnostic tools. Building on the data platform and alerting above, this section sorts the two.

Azure Monitor Insights: curated visualizations

Insights[5] are Microsoft-curated monitoring experiences for a specific resource type: preconfigured dashboards, workbooks, and (sometimes) out-of-the-box alerts built on the same metrics and Log Analytics data you could assemble yourself. The ones an AZ-104 admin reaches for:

  • VM Insights[5]: performance and health of VMs and Virtual Machine Scale Sets at scale, including their processes and dependency map.
  • Storage Insights[5]: a unified view of a storage account's performance, capacity, and availability.
  • Network Insights[5]: health and metrics across all your network resources, with dependency search.
  • Container Insights[5]: performance of AKS-hosted Kubernetes workloads.

Reach for an Insight when you want the page already built; drop to Metrics Explorer or KQL when you need something the Insight doesn't show.

Azure Network Watcher: diagnose the network path

Azure Network Watcher[6] is a regional service for monitoring and diagnosing IaaS network resources (VMs, VNets, gateways, load balancers), not PaaS or web analytics. It is auto-enabled per region when you create a VNet, and there is one Network Watcher instance per region per subscription[6]. Match the symptom to the tool:

Tool Answers Symptom it fixes
IP flow verify[6] Is this packet to/from a VM allowed or denied, and which security rule decided? 'Traffic is blocked and I don't know which NSG rule'
NSG diagnostics[6] Same allow/deny check across IPs, prefixes, or service tags Broader filtering analysis
Next hop[6] What is the next hop type and IP for traffic to a destination? A routing / UDR problem
Effective security rules[6] The aggregate NSG rules applied to a NIC and its subnet 'What rules actually apply here?'
Connection troubleshoot[6] Can source reach destination right now, with latency/hops? A point-in-time connectivity test
Connection monitor[6] The same, continuously, with metrics and alerts Ongoing connectivity SLA monitoring

The pair to keep straight: Connection Troubleshoot tests once, at this moment; Connection Monitor watches over time. Network Watcher also offers Packet capture, VPN troubleshoot, and Flow logs for traffic logging. Note NSG flow logs are being retired (no new ones after June 30, 2025; full retirement September 30, 2027)[6], with virtual network flow logs as the successor.

Exam-pattern recognition

The recurring AZ-104 monitoring stems each map to one right answer with a near-miss distractor that the wording quietly rules out. Building on the mechanics above, these are the patterns and why the wrong option is wrong.

Pattern 1: metric vs log (the data-type tell)

"You need to chart a VM's CPU usage over the last hour with the least configuration. What do you use?"

Answer: Metrics Explorer with platform metrics. They are auto-collected and near-real-time[2], so 'least configuration' rules out anything log-based. The trap is Log Analytics / KQL: it works, but it requires routing data to a workspace first and is the wrong tool for a simple numeric trend. Flip the stem to 'find every user who deleted a resource last week' and the answer flips to Log Analytics (KQL) over the activity log.

Pattern 2: resource logs aren't showing up

"A resource's metrics appear automatically, but its detailed logs are missing from your workspace. Why?"

Because resource logs are off by default[3]: you must create a diagnostic setting that collects them and routes them to the Log Analytics workspace. Platform metrics being present is the deliberate red herring: they're automatic; resource logs are not.

Pattern 3: pick the destination

"Security must stream Azure logs into a third-party SIEM in real time." → Event Hubs (only it streams out). "Keep audit logs for seven years as cheaply as possible." → Storage account (cheapest, kept indefinitely). "Run KQL queries and fire log alerts on the data." → Log Analytics workspace. Each destination[3] maps to one verb (stream, archive, query) and the wrong-verb option is the distractor.

Pattern 4: silence alerts during maintenance

"During a planned maintenance window you must stop alert notifications for a resource group without losing the alert rules."

Answer: an alert processing rule[4] that suppresses notifications on a schedule. The traps are 'disable each alert rule' (loses the rule and you must re-enable manually) and 'delete the action group' (breaks it for every other rule). The processing rule suppresses by filter and lifts automatically.

Pattern 5: which Network Watcher tool

"A VM can't receive traffic on port 443 and you must find the exact rule blocking it." → IP flow verify (names the allowing/denying security rule[6]). "Traffic to a destination is going to the wrong place" → Next hop (routing). "Continuously monitor connectivity between two VMs with alerting" → Connection monitor (the trap is Connection troubleshoot, which only tests once). Match the verb in the stem (which rule, where does it route, continuously) to the tool.

Diagnostic-setting destinations: pick by what you need to do with the data

DestinationPrimary useQuery / consume withCost & retention profile
Log Analytics workspaceQuery, correlate, build workbooks, fire log alertsKQL (Log Analytics), workbooksPay per GB ingested; retention is configurable
Azure Storage accountAudit / compliance archive, static analysis, backupDownload / static tools; immutability policy optionalCheapest; can be kept indefinitely
Azure Event HubsStream to a non-Microsoft SIEM or external systemAny Event Hubs consumer (e.g. SIEM connector)Pay per throughput unit; transient stream, not storage
Azure Monitor partner solutionIntegrate with a partner observability platformThe partner platform's own toolsVaries by partner

Decision tree

Query/correlate with KQLor fire log alerts?Log Analytics workspaceKQL, workbooks, log alertsYesStream live to anexternal SIEM?NoAzure Event Hubsstream out to third partyYesCheap long-termaudit archive?NoAzure Storage accountcheapest, kept indefinitelyYesPartner solutionintegrated partner platformNoOne setting sends one of each type; need two of a kind = a 2nd settingmax 5 diagnostic settings per resource
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Metrics are numeric time series; logs are queryable table rows

Azure Monitor stores telemetry as two types. Metrics are numeric values sampled at regular intervals into a time-series database, so they are lightweight and near-real-time and you read them in Metrics Explorer. Logs are richer records held in a Log Analytics workspace and queried with Kusto Query Language (KQL). A number trending over time (CPU %, request count) is a metric; event-level detail (who deleted what, every failed request) is a log.

Trap Reaching for Log Analytics/KQL to chart a simple numeric trend: it works but needs data routed to a workspace first; Metrics Explorer already has platform metrics for free.

Platform metrics and the activity log are automatic; resource logs are not

Platform metrics (built-in numeric counters) and the activity log (subscription control-plane events) are collected automatically with no configuration. Resource logs, the detailed per-operation logs a service emits, are off by default and produce nothing to query until you create a diagnostic setting. This gap is why a resource shows metrics instantly but its detailed logs are missing from your workspace.

Trap Assuming resource logs appear automatically because metrics did: only metrics and the activity log are automatic; resource logs need a diagnostic setting first.

A diagnostic setting is what collects resource logs and routes any source to a destination

A diagnostic setting does two jobs: it starts collecting resource logs, and it routes platform metrics, the activity log, or resource logs to a durable destination. Even auto-collected sources need a diagnostic setting to send them somewhere they outlive their default window. You opt platform metrics into a destination with the AllMetrics category, and pick log categories individually or via a category group (audit or allLogs).

1 question tests this
A resource can have at most five diagnostic settings

Each Azure resource supports a maximum of five diagnostic settings. A single setting can send to several destinations at once but only one of each type, so two Log Analytics workspaces (or two storage accounts) require two separate settings, and you cannot exceed five total per resource.

Trap Trying to add a second workspace to one diagnostic setting: a setting allows only one destination of each type, so a second workspace needs a second setting (up to five).

Pick the diagnostic-setting destination by the verb: query, archive, or stream

The four destinations map to distinct jobs. A Log Analytics workspace is for querying and correlating with KQL, building workbooks, and firing log alerts. An Azure Storage account is the cheapest archive, kept indefinitely, for audit and compliance. Azure Event Hubs is the only destination that streams telemetry live to an external system such as a non-Microsoft SIEM. A partner solution hands off to an integrated third-party platform.

Trap Choosing a Storage account or Log Analytics workspace to feed a real-time external SIEM: only Event Hubs streams out; the others store data for later retrieval.

Stream to a SIEM with Event Hubs, archive cheaply with a Storage account

When security needs Azure logs streamed into a third-party SIEM in real time, route the diagnostic setting to Azure Event Hubs: the SIEM reads from the hub. When the requirement is keeping audit logs cheaply for years, route to an Azure Storage account, which can be kept indefinitely and supports an immutability policy for tamper-proof records. Storage and Log Analytics hold data; only Event Hubs pushes a live stream.

Metrics Explorer offers exactly five aggregation types

When reading a metric you choose one of five aggregations: Sum (total of all values in the interval, a.k.a. Total), Count (number of samples, ignoring their values), Average (the values' mean, normally Sum/Count), Min (smallest value), and Max (largest value). Picking the wrong aggregation misreads the data: Count on a request-duration metric tells you how many samples there were, not how long requests took.

Average is recalculated from Sum and Count, so Min/Max expose spikes it hides

Sum, Count, Min, and Max are pre-aggregated and stored, but Average is never stored: it is recomputed as Sum ÷ Count for the chosen grain. A short spike can vanish from Average and Sum at coarse granularity while still showing in Min and Max, so to catch transient anomalies inspect Max rather than trusting Average alone.

Trap Using Average to detect a brief spike: averaging smooths it out across the interval; Max is the aggregation that still surfaces the peak.

Metric granularity bottoms out at 1 minute; widen it to cut alert noise

The minimum time granularity (time grain) for charting metrics is 1 minute; coarser grains are computed from the stored 1-minute values. Widening the grain trades detail for noise reduction, which is usually what you want before wiring a metric to an alert so a momentary CPU blip doesn't page you but a sustained one does.

Split a metric by a dimension to find which instance caused a spike

Dimensions are name-value pairs attached to a metric (for example a per-instance breakdown). In Metrics Explorer you split a chart by a dimension to see each value as its own line, or filter to show only some. Splitting is how you turn an aggregated line that shows a spike into the specific instance responsible for it.

One Log Analytics workspace lets a single log search alert span subscriptions and regions

Logs from many resources can land in one Log Analytics workspace regardless of their subscription or region, and KQL queries that workspace across all of them. That is why a single log search alert can monitor resources spread across subscriptions and regions at once, whereas a metric alert is generally scoped to resources of one type in one region.

An alert rule = target + signal/condition + action group

An alert rule binds three things: the target resource to watch, the signal and condition (a metric threshold, a KQL log query, or an activity-log event filter), and an action group to invoke when it fires. Keeping the action group separate from the rule means one action group serves many rules, so you maintain recipients in one place.

Three alert types map to three signals: metric, log search, activity log

Metric alerts evaluate a metric against a static or dynamic threshold at regular intervals: fast and numeric. Log search alerts run a KQL query against workspace logs at a set frequency, for event detail and cross-resource conditions. Activity log alerts fire on a new control-plane event matching a filter. Resource Health and Service Health alerts are themselves activity log alerts.

Trap Treating Resource Health or Service Health as their own alert category: both are implemented as activity log alerts.

An action group bundles reusable notifications and actions

An action group is a named, reusable set of notifications (email, SMS, push, voice) and actions (webhook, secure webhook, Azure Function, Logic App, ITSM, automation runbook, Event Hub). Many alert rules reference the same action group, so the on-call list or remediation runbook is defined once and changed in one place rather than per rule.

3 questions test this
An alert carries a system condition (fired/resolved) and a user response (New/Acknowledged/Closed)

Each fired alert has two independent states. The monitor condition is system-set: fired while the condition holds, then resolved when it clears (a stateful metric alert resolves after the condition is unmet for three consecutive checks). The user response, New, Acknowledged, or Closed, is set by you and never changes on its own. Alert instances are retained for 30 days.

Trap Assuming closing an alert (a user response) clears the underlying problem: the monitor condition only becomes resolved when the actual condition clears, independent of your response.

1 question tests this
Suppress maintenance-window noise with an alert processing rule, not by disabling alerts

An alert processing rule modifies alerts as they fire, by filter and on a schedule, without touching any alert rule. Its two jobs are suppressing notifications (silence a resource group during planned maintenance: rules keep evaluating, only the noise is muted, and suppression lifts automatically) and adding an action group to many alerts at once. Use it instead of disabling or deleting the alert rules.

Trap Disabling each alert rule (or deleting the action group) to go quiet during maintenance: that loses the rule/breaks it for other rules; an alert processing rule suppresses temporarily and reverts on its own.

3 questions test this
Creating an alert rule needs Monitoring Contributor; Monitoring Reader can only view

To create alert rules you need Monitoring Contributor (read on the target resource, write on the resource group holding the rule). Monitoring Reader can view alerts and read resources but cannot create rules. These are the two built-in roles supported at all Resource Manager scopes for alerting.

Insights are curated, ready-made monitoring views for a resource type

Azure Monitor Insights are Microsoft-curated monitoring experiences (preconfigured dashboards, workbooks, and sometimes alerts) built on the same metrics and Log Analytics data you could assemble yourself. The ones an administrator reaches for are VM Insights (VM and scale-set performance, processes, and a dependency map), Storage Insights (account performance, capacity, availability), Network Insights (health and metrics across network resources), and Container Insights (AKS workloads). Use an Insight when you want the page already built.

Network Watcher diagnoses IaaS network paths, not PaaS, and is regional

Azure Network Watcher is a regional service for monitoring and diagnosing the network of IaaS resources (VMs, VNets, gateways, load balancers); it is not designed for PaaS monitoring or web analytics. It is auto-enabled per region when you create a VNet, and there is exactly one Network Watcher instance per region per subscription.

Trap Choosing Network Watcher to monitor a PaaS service's own health: it targets IaaS network paths; for PaaS use that service's metrics, resource logs, and Insights.

IP flow verify names the NSG rule allowing or denying a packet

IP flow verify checks whether a packet to or from a VM is allowed or denied based on the effective network security group rules, and it tells you which security rule made the decision. Reach for it when traffic is blocked and you need to identify the exact NSG rule responsible, rather than reading rules by hand.

Trap Using Next hop to find a blocking firewall rule: Next hop diagnoses routing (where traffic goes), while IP flow verify is the tool that names the allow/deny security rule.

Next hop diagnoses routing; Connection Troubleshoot tests connectivity once

Next hop returns the next hop type and IP for traffic from a VM to a destination, so it diagnoses routing problems such as a misconfigured user-defined route. Connection Troubleshoot tests whether a source can actually reach a destination right now, reporting latency and hops. Next hop answers 'where does this route send the traffic?'; Connection Troubleshoot answers 'can it connect at this moment?'.

Connection Monitor watches connectivity continuously; Connection Troubleshoot is a one-time test

Connection Monitor provides ongoing end-to-end connectivity monitoring between endpoints, with metrics and alerts over time. Connection Troubleshoot performs the same kind of check but only at a single point in time. When a scenario needs continuous monitoring with alerting, choose Connection Monitor; for a one-off diagnosis, Connection Troubleshoot.

Trap Using Connection Troubleshoot for ongoing connectivity SLA monitoring: it tests once at that moment; Connection Monitor is the continuous, alert-capable tool.

Migrate NSG flow logs to VNet flow logs before the 2027 retirement

Network Watcher flow logs record IP traffic for traffic analysis. NSG flow logs are being retired: no new ones can be created after June 30, 2025, and they are fully retired on September 30, 2027. Virtual network (VNet) flow logs are the successor and address NSG flow log limitations, so new logging should use VNet flow logs.

Trap Creating new NSG flow logs for traffic logging: they are end-of-life (no new ones after June 30, 2025; retired September 30, 2027); use virtual network flow logs instead.

VM Insights needs a Log Analytics workspace, the Azure Monitor Agent, and a DCR

Before VM Insights can collect performance data it needs a Log Analytics workspace (data lands in the InsightsMetrics table), the Azure Monitor Agent on the VM, and a data collection rule (DCR) that tells the agent what to collect. The default VM Insights DCR gathers guest performance only: it does not collect Windows event logs or Syslog, so add a separate DCR for those. A VM Insights DCR must already exist before you assign an Azure Policy initiative to onboard VMs at scale.

Trap VM Insights does not collect event logs/Syslog out of the box; you create an additional DCR rather than editing the VM Insights one.

9 questions test this
The VM Insights Map feature requires the Dependency Agent; performance does not

VM Insights has two features: Performance (Azure Monitor Agent only) and Map. The Map view of processes and application dependencies needs the Dependency Agent (the 'processes and dependencies' option) installed in addition to the Azure Monitor Agent. The portal's default data collection rule enables guest performance but leaves processes-and-dependencies (Map) disabled, so by default only the Azure Monitor Agent is installed and the Map view shows no data.

Trap Empty Map view with working Performance data means the Dependency Agent is missing, not a workspace or DCR problem.

5 questions test this
KQL essentials: summarize with bin() for time buckets, project to pick columns, render to chart

In Log Analytics KQL, summarize aggregates rows and bin(TimeGenerated, 1h) buckets results into time intervals (e.g. hourly average per Computer). project selects, renames, or drops specific columns. render (e.g. render timechart) must be the last operator and turns query results into a visualization.

Trap bin() groups the time axis inside summarize: it is not the operator that draws the chart (that is render).

5 questions test this
Azure Workbooks combine logs, metrics, Resource Graph, text, and parameters into one interactive report

Azure Workbooks are the tool when you must blend Azure Monitor Logs, metrics, and Azure Resource Graph data in a single interactive report with embedded text, then let users filter via parameters (time range, resource selectors) and export to PDF. Azure Resource Graph is a supported data source for querying resource inventory and metadata (location, tags) across subscriptions to scope a report.

Trap Parameters (not editing the KQL) are what let consumers filter a workbook interactively.

8 questions test this
Action group notifications are rate limited: email 100/hour, SMS and voice 1 per 5 minutes

Azure Monitor rate-limits action group notifications per recipient: email is capped at no more than 100 emails per hour to each email address (per region), and SMS and voice calls at no more than one notification every five minutes per phone number. Once the limit is hit, further notifications are dropped until the window expires, which is the usual reason an admin stops receiving alerts even though alerts are firing.

Trap Missing notifications with alerts clearly firing usually means rate limiting, not a wrong email/phone or an unsubscribe.

5 questions test this
Service Health alerts need a Global action group; inactive events stay in Health History for 90 days

Azure Service Health reports subscription-wide event types including Service issues, Planned maintenance, Health advisories, Security advisories, and Billing updates. To be notified of planned maintenance you create a Service Health (activity log) alert plus an action group, and the action group region must be set to Global for Service Health alerts to work. Inactive Service Health events are retained in Health History for up to 90 days after they become inactive.

Trap An action group used for a Service Health alert must be in the Global region, not a specific Azure region.

6 questions test this
Resource Health reports a single resource's availability and whether an issue was platform- or user-initiated

Resource Health shows the health of an individual resource (such as one VM) and its reason type tells you whether unavailability was platform-initiated (Azure maintenance/host issue) or user-initiated (e.g. a manual stop or deallocate). A Resource Health status of Unknown means Azure has had no data about the resource for over 10 minutes, which commonly happens when a VM is deallocated.

Trap Service Health is for subscription-wide Azure incidents; Resource Health is the one that drills into a specific resource instance.

5 questions test this

Also tested in

References

  1. Azure Monitor overview
  2. Azure Monitor metrics aggregation and display explained
  3. Diagnostic settings in Azure Monitor
  4. Overview of Azure Monitor alerts
  5. Azure Monitor Insights overview
  6. Azure Network Watcher overview