The last bullet group in the AZ-900 skills outline is short enough to fit on a sticky note: describe the purpose of Azure Advisor; describe Azure Service Health; describe Azure Monitor, including Log Analytics, Azure Monitor alerts, and Azure Monitor Application Insights. Five names, three bullets, and in the Skills measured as of July 20, 2026 the section was flagged as a “minor” change rather than a rewrite. It is tempting to skim it.
That would be a mistake, because the exam does not ask you to define the five tools. It describes a situation and asks which tool is the right one, and the five overlap just enough to make that hard. Azure Monitor has alerts; Service Health has alerts; Advisor has alerts. Application Insights stores its data in a Log Analytics workspace, so is it “part of” Log Analytics? Service Health and Resource Health both report outages, so which one tells you a specific virtual machine is down?
The sibling guide on Azure management and governance for AZ-900 introduces the monitoring tools in a few paragraphs alongside cost management, Azure Policy and resource locks. This article goes deeper on just the monitoring objective: what each tool actually collects or reports, how they fit together, and the decision rules that resolve the exam’s favourite confusions.
What the Objective Is Really Testing
Microsoft’s monitoring tools answer three distinct questions, and almost every exam scenario is one of them in disguise:
| Question | Tool | What it looks at |
|---|---|---|
| ”What is happening inside my resources and applications right now?” | Azure Monitor (with Log Analytics, alerts and Application Insights) | Your telemetry: metrics, logs, traces |
| ”How could I run my environment better?” | Azure Advisor | Your configuration and usage, compared to best practice |
| ”Is Azure itself having a problem that affects me?” | Azure Service Health (with Azure status and Resource Health) | Microsoft’s platform events: outages, maintenance, advisories |
Hold on to the three questions. Azure Monitor is about your data. Advisor is about advice. Service Health is about Microsoft’s platform. When a question mentions CPU percentages, request latency or a KQL query, it is Azure Monitor. When it mentions “recommendations”, “best practices” or “underutilised”, it is Advisor. When it mentions “planned maintenance”, “outage in a region” or “is this Microsoft’s fault”, it is Service Health.
Azure Monitor: The Platform
Azure Monitor is, in Microsoft’s current wording, the “unified observability service for collecting, analyzing, and acting on telemetry from cloud and hybrid environments”. Everything else in this objective either lives inside it (Log Analytics, alerts, Application Insights) or feeds it (Service Health events can trigger Azure Monitor alerts; Advisor recommendations can be surfaced through it).
What It Collects
Azure Monitor brings together four kinds of telemetry:
- Metrics: numeric values sampled at regular intervals, such as CPU percentage, disk IOPS, or HTTP request count. Lightweight, near real-time, and ideal for charts and threshold alerts.
- Logs: records of events, with text and structured properties. Richer than metrics, queryable, and slower to arrive.
- Traces: the path of a single request through the components of a distributed application. The domain of Application Insights.
- Changes: what was modified in your resources and when, used to correlate incidents with deployments.
Those come from every layer of an Azure estate: the application code, the guest operating system of a virtual machine (via the Azure Monitor Agent), the Azure resources themselves, the subscription (the Activity log, which records every control-plane operation such as “VM started” or “resource group deleted”) and the tenant (Microsoft Entra ID sign-in and audit logs). Through Azure Arc, servers and Kubernetes clusters running on-premises or in other clouds can be onboarded and monitored the same way, which is the hybrid angle the exam occasionally probes.
Two Kinds of Workspace
A detail that has crept into the current documentation and is worth knowing even at fundamentals level: Azure Monitor now has two workspace types, and the names are confusingly similar.
| Workspace | Stores | Query language |
|---|---|---|
| Log Analytics workspace | Log and trace data | KQL (Kusto Query Language) |
| Azure Monitor workspace | Prometheus and OpenTelemetry metrics | PromQL |
The documentation notes that “these are separate resource types with different data stores and query languages”. For the AZ-900, the Log Analytics workspace is the one that matters: it is where logs live, and it is the one the objective names.
What You Do With the Data
Microsoft organises Azure Monitor’s features into a handful of verbs, and knowing them helps decode scenario wording:
- Insights: curated, opinionated monitoring experiences for specific resource types. Application Insights for applications, VM insights for virtual machines, Container insights for Kubernetes, Network insights for networking. If a question says “a pre-built dashboard for AKS”, it means Container insights.
- Visualize: workbooks (interactive reports), Azure dashboards, and Grafana dashboards in the portal, plus export to Power BI.
- Analyze: Metrics explorer for charting metrics and Log Analytics for querying logs.
- Respond: alerts (notify or automate when a condition is met) and autoscale (add or remove instances based on metrics or a schedule).
- Integrate: send data onward to Event Hubs, Logic Apps, or third-party tools.
The exam reduces this to a sentence worth memorising: Azure Monitor collects metrics and logs from Azure resources and applications, lets you analyse them, and lets you alert and automate on them.
Log Analytics: The Tool and the Workspace
“Log Analytics” is used for two things in Microsoft’s documentation, and the exam will happily exploit the ambiguity.
The Log Analytics workspace is a resource: a container in which Azure Monitor log data is stored. You create one, point data sources at it (diagnostic settings on resources, the Azure Monitor Agent on VMs, Application Insights), and it accumulates tables of records. Retention, access control and pricing are configured per workspace.
The Log Analytics tool is the query editor in the Azure portal. The documentation defines it as the tool that “lets you run and edit log queries against data in the Azure Monitor Logs store”. You open it by selecting Logs in Azure Monitor, in a workspace, or on an individual resource; starting from a resource scopes the query to that resource’s data.
The query language is KQL, the Kusto Query Language, which Log Analytics shares with Azure Data Explorer and Microsoft Sentinel. A beginner-level query the exam might show looks like this:
Heartbeat
| where TimeGenerated > ago(1h)
| summarize LastBeat = max(TimeGenerated) by Computer
| where LastBeat < ago(10m)That lists machines that have stopped reporting in the last ten minutes. You do not need to write KQL for AZ-900, but you should recognise it, and you should know that the current Log Analytics tool also offers a simple mode, a point-and-click experience with no query language, alongside the full KQL mode.
Two facts tie Log Analytics to the rest of the objective:
- Log search alerts are alert rules that run a KQL query on a schedule and fire when the results meet a condition. So Log Analytics is not only for investigation; it is the engine behind log-based alerting.
- Application Insights is workspace-based: its telemetry is stored in a Log Analytics workspace, which is why you can query application traces with KQL alongside infrastructure logs.
The exam distinction: Azure Monitor is the platform, the Log Analytics workspace is where logs are stored, and Log Analytics is where you query them with KQL.
Application Insights: Monitoring the Application
Application Insights is the application performance monitoring (APM) feature of Azure Monitor. Where VM insights watches the machine and Container insights watches the cluster, Application Insights watches the code: how many requests it serves, how fast, how often they fail, which dependencies (databases, HTTP calls, queues) they wait on, and what exceptions they throw.
How Data Gets In
The current implementation is built on OpenTelemetry (OTel), the vendor-neutral observability standard. The documentation describes Application Insights as “an OpenTelemetry feature of Azure Monitor that offers application performance monitoring (APM) for live web applications”. In practice:
- Server-side apps in .NET, Node.js, Python and Java add an OpenTelemetry distribution and a connection string that points at the Application Insights resource.
- Some hosting platforms, such as App Service and Azure Functions, offer automatic instrumentation with no code changes.
- Browser apps use the Application Insights JavaScript SDK (not OpenTelemetry) to capture page views and client-side errors.
What You Get
The portal experiences the exam is most likely to name:
| Experience | What it shows |
|---|---|
| Application map | A topology diagram of the application’s components and their dependencies, with health overlaid |
| Live metrics | A real-time stream of request rates, failures and performance, with roughly one-second latency |
| Failures and Performance views | Which operations fail or are slow, drilled down to individual transactions |
| Availability tests | Synthetic probes that hit your endpoints from Azure regions on a schedule and alert if they fail |
| Usage (users, sessions, funnels, flows, cohorts) | How people actually use the application |
| Smart detection | Machine-learning detection of failure and performance anomalies |
The exam rule: if the scenario is about application behaviour (response times, exceptions, dependency failures, user flows, a web app that is “slow for some users”), the answer is Application Insights. If it is about infrastructure (CPU, memory, disk, a VM that will not start), it is Azure Monitor metrics, VM insights or Log Analytics. Application Insights is the only one of the five tools that understands HTTP requests and code-level exceptions.
Azure Monitor Alerts
Alerts are the “respond” half of Azure Monitor and the part of the objective with the most moving parts.
Anatomy of an Alert Rule
An alert rule combines three things, in the documentation’s words: “the resources to be monitored”, “the signal or data from the resource”, and “conditions”. For example: resource = a virtual machine; signal = the Percentage CPU metric; condition = greater than 90% averaged over five minutes.
When the condition is met, an alert fires. Firing does two things: it records an alert instance (visible on the Alerts page for 30 days, after which it is deleted) and it triggers the rule’s action group.
Action Groups
An action group is a reusable list of what to do when an alert fires. The exam tends to split its contents into notifications and automation:
- Notifications: email, SMS, push notification to the Azure mobile app, voice call.
- Actions: Automation runbooks, Azure Functions, Logic Apps, webhooks and secure webhooks, ITSM incidents, Event Hubs.
One action group can serve many alert rules, which is the point: define “page the on-call team” once and attach it everywhere.
Alert Types
| Alert type | Evaluates | Typical use |
|---|---|---|
| Metric alerts | Resource metrics at regular intervals; supports dynamic thresholds that learn the normal pattern | CPU above 90%, queue length growing |
| Log search alerts | A Log Analytics (KQL) query on a schedule | More than 50 failed sign-ins in 15 minutes |
| Activity log alerts | New Activity log events matching a filter | Someone deleted a resource group; a Service Health event was published |
| Smart detection alerts | Application Insights anomaly detection | Unusual rise in failed requests |
| Prometheus alerts | PromQL on Azure Monitor managed Prometheus | Kubernetes workload metrics |
The row to underline is activity log alerts, because the documentation says explicitly that “Resource Health alerts and Service Health alerts are activity log alerts”. That is the mechanical link between Service Health and Azure Monitor: a Service Health alert is an Azure Monitor alert rule whose signal is the Activity log’s Service Health category, wired to an action group.
Alert States and Severity
Each fired alert has two independent states:
- The alert condition, set by the system:
firedwhen the condition is met,resolvedwhen it clears (for stateful alerts). - The user response, set by a human: New, Acknowledged or Closed. It never changes on its own.
Alerts also carry a severity from 0 to 4 (Critical, Error, Warning, Informational, Verbose) chosen by the rule’s author. Severity is a label for triage, not a behaviour.
Finally, alerts are stateful or stateless. A stateful alert fires once and does not fire again until the condition resolves; a stateless alert fires every time the condition is evaluated as true. All activity log alerts are stateless. A metric alert is considered resolved when the condition is not met for three consecutive checks. Alert processing rules sit on top of all of this and let you suppress notifications (during a maintenance window, say) or add action groups across many rules at once.
For the AZ-900, the depth required is: alert rule = scope + signal + condition; action group = who gets told and what runs; metric alerts versus log search alerts versus activity log alerts; and the fact that Service Health alerts are built on the same machinery.
Azure Advisor: Personalised Recommendations
Azure Advisor is the tool that answers “how could I run this better?”. Microsoft calls it “a digital cloud assistant that helps you follow best practices to optimize your Azure deployments”. It inspects your resource configuration and usage telemetry and produces personalised, actionable recommendations, most with a one-click or guided remediation.
The Five Categories
Advisor organises every recommendation into five categories, and the exam expects you to know them as a set:
| Category | Purpose (per the documentation) | Example recommendation |
|---|---|---|
| Reliability | ”Ensure and improve the continuity of your business-critical applications” | Enable backup on this VM; add a second instance to this availability set |
| Security | ”Detect threats and vulnerabilities that might lead to security breaches” | Enable MFA; close an exposed management port |
| Performance | ”Improve the speed of your applications” | Upgrade a storage account to premium; enable accelerated networking |
| Cost | ”Optimize and reduce your overall Azure spending” | Right-size or shut down an underutilised VM; buy a reservation |
| Operational excellence | ”Achieve process and workflow efficiency, resource manageability, and deployment best practices” | Create a Service Health alert; add tags; repair invalid Azure Policy assignments |
Older study material lists four categories (it predates operational excellence); the current count is five. Note also that the security recommendations are not Advisor’s own. The documentation states that Advisor “includes your recommendations from Microsoft Defender for Cloud”, so the same item appears in both places. The Defender for Cloud guide explains where those recommendations and the secure score originate.
Practical Facts the Exam Can Ask
- Advisor is free. There is no plan to enable and no per-resource charge.
- It is personalised: it only recommends changes for resources you actually have, based on their configuration and usage.
- You need Owner, Contributor or Reader on the subscription, resource group or resource to see its recommendations.
- Recommendations can be marked Postponed, Dismissed or Completed. Postponing hides a recommendation temporarily; dismissing says it is not relevant. After you implement a fix, it “can take up to a day for Advisor to recognize the action”.
- An Advisor score summarises how well a subscription follows best practice across the categories, and Advisor alerts can notify you when new recommendations appear.
The decision rule: Advisor is proactive and advisory. It does not monitor telemetry in real time (that is Azure Monitor), it does not detect attacks (Defender for Cloud), and it does not enforce anything (Azure Policy). If the scenario asks for a prioritised list of improvements, it is Advisor.
Azure Service Health: Is It Azure, or Is It Me?
Service Health answers the question every operator asks first during an incident. Microsoft describes it as “a combination of three separate services”, and the exam tests the boundaries between them.
Azure Status
The Azure status page (azure.status.microsoft) is public and global: “a global view of the health of all Azure services across all Azure regions”. It requires no sign-in and knows nothing about your subscription. It is useful for widespread incidents and useless for anything specific to you, which is why the documentation “strongly recommends” that current customers use Service Health instead.
Service Health
Service Health in the Azure portal is the personalised layer: “a personalized view of the health of the Azure services and regions you use”. It filters Microsoft’s platform events to the subscriptions, services and regions you actually depend on. The portal tracks five event types:
| Event type | What it means |
|---|---|
| Service issues | ”Problems in the Azure services that affect you right now” (an outage) |
| Planned maintenance | ”Upcoming maintenance that can affect the availability of your services in the future” |
| Health advisories | ”Changes in Azure services that require your attention”, such as feature deprecations or required upgrades |
| Security advisories | ”Security-related notifications or violations that might affect the availability of your Azure services” |
| Billing updates | ”Billing communications related to your subscription” (visible to subscription Owners and Contributors) |
Events are kept in Health history for 90 days after they become inactive. Service Health alerts are configured from this dashboard and, as noted above, are implemented as activity log alert rules attached to an action group, so “email the operations team when a service issue affects West Europe” is a Service Health alert plus an action group.
Resource Health
Resource Health narrows the view to a single resource: “the health of your individual cloud resources, such as a specific virtual machine instance”. It reports one of four statuses:
| Status | Meaning |
|---|---|
| Available | No events detected affecting the resource (a “recently resolved” note appears if it recovered in the last 24 hours) |
| Unavailable | An ongoing platform or non-platform event is affecting the resource |
| Degraded | The resource “detected a loss in performance, although it’s still available for use” |
| Unknown | Resource Health has had no information for more than 10 minutes, commonly because a VM is deallocated |
The distinction inside Unavailable is one the exam likes: platform events are triggered by Azure infrastructure (planned maintenance, an unplanned host reboot, hardware predicted to fail), while non-platform events are triggered by user actions, such as stopping a virtual machine. Resource Health shows both, and it keeps 30 days of history per resource, which, as the documentation points out, “makes it easy for you to see if a Service Level Agreement (SLA) was violated”.
The Three-Way Decision
| Scenario wording | Answer |
|---|---|
| ”Is there a global Azure outage?” without signing in | Azure status page |
| ”Will any planned maintenance affect my services next week?” | Service Health (planned maintenance) |
| “Notify my team when Azure has an issue in the regions we use” | Service Health alert with an action group |
| ”Is this specific VM down because of Azure or because someone stopped it?” | Resource Health |
| ”Did Azure breach the SLA for my database last month?” | Resource Health history |
| ”Is my VM’s CPU at 100%?” | Not Service Health at all: Azure Monitor metrics |
Putting the Five Tools Side by Side
| Azure Monitor | Log Analytics | Application Insights | Azure Advisor | Service Health | |
|---|---|---|---|---|---|
| Looks at | Your telemetry (metrics, logs, traces) | Logs in a workspace | Application requests, dependencies, exceptions | Your configuration and usage | Microsoft’s platform events |
| Core output | Charts, alerts, autoscale | KQL query results | APM views, application map, live metrics | Prioritised recommendations in 5 categories | Service issues, maintenance, advisories; resource status |
| Timeframe | Real time and historical | Historical (seconds to years) | Real time and historical | Periodic re-evaluation | As Microsoft publishes events |
| Cost | Pay for data ingested and retained | Part of Azure Monitor pricing | Part of Azure Monitor pricing | Free | Free |
| Answers | ”What is happening?" | "Show me the records where…" | "Why is my app slow or failing?" | "What should I improve?" | "Is it Azure?” |
Worked Exam Scenarios
Scenario 1. A company wants to be notified by SMS whenever a virtual machine’s average CPU exceeds 85% for ten minutes. Create an Azure Monitor metric alert rule scoped to the VM, with a condition on the Percentage CPU signal, attached to an action group containing an SMS notification. Not Advisor (it does not watch real-time metrics) and not Service Health (CPU is your telemetry, not a platform event).
Scenario 2. An administrator needs a list of all Azure services that could be made cheaper or more resilient, ranked by impact. Azure Advisor, specifically the Cost and Reliability categories. The words “list”, “recommendations” and “ranked” are the giveaways.
Scenario 3. A web application is returning errors for some users, and the developers want to see which downstream dependency is failing. Application Insights, using the Application map and the Failures view. Only Application Insights understands requests and dependencies.
Scenario 4. A VM became unreachable overnight. The team needs to know whether Azure had an infrastructure problem on that host or whether a colleague stopped the machine. Resource Health, which distinguishes platform events from non-platform (user-initiated) events for that specific resource.
Scenario 5. The security team wants to query sign-in logs and VM security events together using a single language. Send both to a Log Analytics workspace and query with KQL in Log Analytics. The question is about correlating stored logs, not about alerting or recommendations.
Scenario 6. Microsoft is retiring a feature your solution relies on and you want to be told in advance. Service Health, via a health advisory, ideally with a Service Health alert so nobody has to check the portal.
Scenario 7. A Service Health alert must email the operations distribution list and open a ticket in the company’s ITSM tool. An action group with an email notification and an ITSM action, attached to the Service Health alert rule. One action group, two actions.
Common Mistakes to Avoid
- Treating Log Analytics as a separate product from Azure Monitor. It is Azure Monitor’s log store and query tool. The question “which Azure Monitor component stores logs?” has the answer “a Log Analytics workspace”.
- Confusing the Log Analytics tool with the workspace. The workspace stores; the tool queries. Both are called Log Analytics.
- Picking Application Insights for infrastructure questions. It is APM. A disk-full alert is a metric alert, not an Application Insights feature.
- Picking Service Health for your own resource’s metrics. Service Health only knows about Microsoft’s platform events. High CPU is not a Service Health event.
- Confusing Service Health with Resource Health. Service Health is about services and regions you use; Resource Health is about one resource. “This VM” means Resource Health.
- Listing four Advisor categories. There are five: reliability, security, performance, cost, operational excellence.
- Assuming Advisor costs money or acts automatically. It is free and advisory; you choose whether to apply its recommendations.
- Forgetting that action groups are reusable and separate from rules. A rule says when; an action group says who and what. Several rules can share one group.
- Thinking alerts are only notifications. An action group can run automation (runbooks, Functions, Logic Apps), which is how a metric alert can trigger remediation.
- Missing the Activity log. It is the subscription-level audit trail of control-plane operations and the signal behind activity log alerts, including Service Health and Resource Health alerts.
How to Lock This In Before Exam Day
Open the Azure portal with a free account and spend thirty minutes touring the five tools in order. Go to Monitor, open Metrics and chart a storage account’s transactions; open Logs and run a one-line query such as AzureActivity | take 10; create a throwaway alert rule and notice that the wizard asks for a scope, a signal, a condition and an action group in that order. Open Advisor and count the five category tiles. Open Service Health, click through the five event types, then open Resource health on any resource and read its status. Finally, open the public Azure status page in a private window and notice that it knows nothing about your subscription.
Then test yourself under exam conditions. The free AZ-900 practice questions include monitoring scenarios in the “which tool?” style used above, and the AZ-900 practice exam page offers a sample set you can try without an account. For a full, domain-weighted rehearsal across all three skill areas, the AZ-900 Azure Fundamentals Mock Exam Bundle includes six timed mock exams whose management-and-governance questions cover the monitoring tools at exactly this altitude, with explanations that spell out why the distractors are wrong. The 30-day AZ-900 study plan schedules the monitoring topics for day 20, and the AZ-900 exam guide maps the rest of the management and governance domain.
Conclusion
The AZ-900 monitoring objective is three questions wearing five names. Azure Monitor is the platform that collects your metrics, logs and traces; inside it, the Log Analytics workspace stores logs and the Log Analytics tool queries them with KQL, Application Insights watches your application code through OpenTelemetry, and alerts turn conditions into notifications and automation through reusable action groups. Azure Advisor reads your configuration and hands back free, personalised recommendations in five categories. Azure Service Health tells you whether the problem is Microsoft’s, with the public Azure status page for the world, Service Health for the services and regions you use, and Resource Health for a single resource and its four statuses.
Remember the boundaries (your telemetry versus advice versus Microsoft’s platform), the two meanings of Log Analytics, the five Advisor categories, the five Service Health event types, the four Resource Health statuses, and the fact that Service Health alerts are activity log alerts in Azure Monitor. With those in place, the “which tool?” questions in this domain become some of the most predictable marks on the exam.
Frequently Asked Questions
What is the difference between Azure Monitor, Log Analytics and Application Insights?
Azure Monitor is the overall observability platform that collects metrics, logs and traces from Azure resources and applications. A Log Analytics workspace is the Azure Monitor component that stores log data, and the Log Analytics tool is where you query that data with KQL. Application Insights is the application performance monitoring feature of Azure Monitor: it instruments your application code to track requests, dependencies, exceptions and usage, and it stores its data in a Log Analytics workspace.
What are the five Azure Advisor recommendation categories?
Reliability, Security, Performance, Cost and Operational excellence. Advisor is free, personalised to the resources you actually run, and includes the security recommendations generated by Microsoft Defender for Cloud. Recommendations can be postponed, dismissed or marked completed.
What is the difference between Azure Service Health and Resource Health?
Service Health gives a personalised view of Microsoft platform events (service issues, planned maintenance, health advisories, security advisories and billing updates) for the services and regions your subscriptions use. Resource Health reports the current and past health of one specific resource, such as a single virtual machine, with the statuses Available, Unavailable, Degraded and Unknown, and distinguishes platform events from user-initiated ones. Both are free and both sit under the Service Health service alongside the public Azure status page.
How do Azure Monitor alerts work?
An alert rule defines a scope (the resources to watch), a signal (a metric, a log query, an activity log event, or an Application Insights anomaly) and a condition. When the condition is met the alert fires, and an attached action group sends notifications (email, SMS, push, voice) or runs automation (runbooks, Functions, Logic Apps, webhooks, ITSM). Alerts have a system-set condition (fired or resolved) and a user-set response (New, Acknowledged, Closed), and fired alerts are kept for 30 days.
Is Azure Service Health the same as the Azure status page?
No. The Azure status page is public and global, showing the health of all services in all regions without any sign-in and without knowledge of your subscription. Service Health is the personalised, in-portal view filtered to what you use, and it is the one Microsoft recommends for current customers. Service Health alerts are implemented as activity log alert rules in Azure Monitor.
Do I need to know KQL for the AZ-900 exam?
No. You should know that KQL (Kusto Query Language) is the language used to query a Log Analytics workspace, that Log Analytics is where you run those queries, and that log search alerts are built on KQL queries. Writing queries is AZ-104 and AZ-500 territory, not AZ-900.
Which monitoring tool tells me if a VM stopped because of Azure or because a user stopped it?
Resource Health. For an Unavailable resource it distinguishes platform events, such as planned maintenance or an unplanned host reboot, from non-platform events triggered by user actions, such as stopping the virtual machine, and keeps 30 days of history.
Is Azure Advisor free?
Yes. Advisor has no plan to enable and no charge; anyone with Owner, Contributor or Reader access to a subscription, resource group or resource can view its recommendations. The only cost is any you choose to incur by acting on a recommendation.