Welcome, future Azure Administrator. You’ve provisioned virtual machines, configured networks, and secured identities. But the real work of an administrator begins after deployment. The “Monitor and maintain Azure resources” domain, which accounts for a significant 20-25% of your AZ-104 exam, is the heart of operational excellence. It’s about ensuring performance, availability, and security. It’s the difference between a reactive “firefighter” and a proactive, strategic administrator.
In my years of training thousands of professionals, I’ve seen many students master resource deployment but stumble when it comes to monitoring. Why? Because monitoring isn’t just about looking at dashboards; it’s an architectural discipline. This guide is designed to bridge that gap. We won’t just list services; we’ll dissect the “why” behind the “how,” grounding every concept in real-world scenarios you’ll face on the job and tricky questions you’ll encounter on the exam. By the end of this deep dive, you will not only be prepared to pass the AZ-104 but will also possess the foundational knowledge to maintain a robust, reliable, and efficient Azure environment. If you’re still planning your exam journey, check out our AZ-104 Study Plan for a structured preparation guide.

The Pillars of Observability in Azure
Before diving into specific tools, it’s crucial to understand the foundational data types that underpin all monitoring activities in Azure. Think of these as the raw ingredients you’ll use to diagnose issues, create alerts, and gain insights.
- Metrics: These are numerical, time-series data points collected at regular intervals. They are lightweight and ideal for near-real-time alerting and performance analysis. Think of metrics as the pulse of your system: CPU percentage, network in/out, disk IOPS. They tell you that something is happening.
- Logs: These are structured or unstructured event records with rich contextual information. Logs provide the “why” behind the “what.” Think of them as a detailed journal: application errors, security audit events, web server requests. They are more detailed than metrics but have higher latency.
- Traces: These show the end-to-end journey of a request as it travels through various services in a distributed system. While more of a developer-centric concept (and a key part of Application Insights), as an admin, you need to understand traces to help diagnose complex, multi-service application failures.
Exam Tip: The AZ-104 exam will frequently test your ability to choose the right data type for a given scenario. Remember this mnemonic: Metrics for Measurement (fast, numerical, “what”), Logs for Logic (detailed, contextual, “why”).
The Core Engine: Azure Monitor
Azure Monitor is the central, unified platform for collecting, analyzing, and acting on telemetry from your Azure and on-premises environments. It’s not a single tool but a comprehensive suite of services that ingests both metrics and logs. From an architectural standpoint, nearly every monitoring capability in Azure either feeds into or pulls from Azure Monitor.
Data Collection: The Foundation of Insight
Your monitoring is only as good as the data you collect. Azure Monitor gathers data from a variety of sources:
- Platform Metrics & Logs: Data automatically generated by Azure resources (VMs, App Services, Storage Accounts). This includes things like CPU usage on a VM or the number of transactions on a storage account.
- Guest OS Data (VMs): To see what’s happening inside a virtual machine (e.g., memory usage, event logs, specific process performance), you need an agent.
- Application Data: Performance and event data from your applications, typically collected via an SDK (like Application Insights).
- Custom Sources: You can send data from any source using APIs.
The Agent Evolution: AMA vs. Legacy Agents (Crucial 2026 Update)
This is one of the most significant recent changes and a critical exam topic. For years, Azure used multiple agents (Log Analytics Agent, Diagnostic Extension, Telegraf). Microsoft has consolidated these into the Azure Monitor Agent (AMA).
| Data Collection | Centralized using Data Collection Rules (DCRs) | Configured separately for each workspace |
|---|---|---|
| Destinations | Can send to multiple Log Analytics Workspaces | Can only send to a single Log Analytics Workspace |
| Data Types | Collects both logs and metrics | Primarily collects logs |
| Filtering | Granular filtering at the source (reduces cost) | Sends all data, filtering happens at ingestion |
| Support | Fully supported and recommended | Deprecation announced (September 2026) |
Real-World Scenario: You manage 100 VMs. 50 belong to the Finance department and 50 to HR. You need to send security events from all VMs to a central security workspace, but performance counters only to their respective departmental workspaces.
- Old Way (MMA): This was complex and might require multiple agents or custom forwarding configurations.
- New Way (AMA): You create one Data Collection Rule (DCR) to send security events to the security LAW and a second DCR to send performance data to the departmental LAWs. You then associate both DCRs with all 100 VMs. This is efficient, scalable, and cost-effective.
Exam Tip: If you see a question about collecting data from VMs, the modern, correct answer will almost always involve the Azure Monitor Agent (AMA) and Data Collection Rules (DCRs). Understand that a DCR defines what data to collect and where to send it. If you’re new to Azure and considering which certification to start with, read AZ-900 vs AZ-104 to choose wisely.
Analyzing Performance with Azure Monitor Metrics
Azure Monitor Metrics is your primary tool for analyzing time-series performance data. Its main interface is the Metrics Explorer.
Mastering Metrics Explorer
Metrics Explorer is an interactive charting tool in the Azure portal that allows you to plot metrics, visually correlate trends, and investigate spikes and dips in performance.
Key Concepts to Master:
- Scope: The resource you are analyzing (e.g., a specific VM, a storage account).
- Metric Namespace: A category of metrics (e.g., “Virtual Machine Host Metrics”).
- Metric: The specific counter you want to see (e.g., “Percentage CPU”).
- Aggregation: How the data points are summarized over a time period (e.g.,
Avg,Sum,Min,Max). - Splitting (Dimension): This is the most powerful feature. It allows you to segment a metric by a specific property. For example, you can view the “Transactions” metric on a storage account and split it by “API Name” to see which API call (e.g.,
GetBlob,PutBlob) is causing the most traffic.
Real-World Scenario: Users are complaining that your e-commerce website, hosted on a Virtual Machine Scale Set (VMSS), is slow. You suspect a CPU issue.
- Navigate to your VMSS resource in the Azure portal.
- Open Metrics under the “Monitoring” blade.
- Select the Metric “Percentage CPU”. The aggregation defaults to
Avg, which is perfect. - You see the average CPU is high, around 90%. But which instance is the problem?
- Click Apply splitting and select the “Virtual Machine” dimension.
- The chart now displays a separate line for each VM instance in the scale set. You instantly identify that two out of ten instances are pegged at 100% CPU while the others are normal.
- Action: You can now investigate those specific instances for runaway processes, proving that the issue isn’t the entire application but isolated problem machines.
Deep Diagnostics with Azure Monitor Logs and Log Analytics
While metrics tell you that CPU is high, logs tell you why (e.g., a specific process w3wp.exe is consuming all the cycles). Azure Monitor Logs is the service that collects and organizes log and performance data, and Log Analytics Workspace (LAW) is the environment where you query and analyze that data.
The Log Analytics Workspace (LAW): Your Operational Data Hub
A Log Analytics Workspace is a unique environment for Azure Monitor log data. It’s essentially a massive, queryable data lake for all your operational telemetry. For more insight into certification career outcomes, explore AZ-104 Certification Worth and AZ-104 Certification Cost, Salary, and Jobs.
Best Practice: Don’t create a LAW for every resource. Design a workspace strategy. A common architectural pattern is to have a centralized workspace per region for all operational data, with potentially a separate workspace for security data that might have different retention and access control requirements.
Kusto Query Language (KQL): The Language of Insight
To extract value from your logs, you must speak their language: Kusto Query Language (KQL). While it might seem intimidating, it’s incredibly powerful and relatively simple to start. The AZ-104 exam doesn’t require you to be a KQL wizard, but you must understand its basic structure and be able to interpret simple queries.
KQL uses a pipeline structure. Data flows from one operator to the next.
// Find all error events from the 'Event' table in the last 24 hours
Event
| where TimeGenerated > ago(24h)
| where EventLevelName == "Error"
| project TimeGenerated, Source, RenderedDescription // Select specific columns to display
| take 100 // Limit the results
Memory Technique (Mnemonic for KQL): Think “Where, What, How Many?”
- Where:
wherefilters the data (time, severity, etc.). - What:
projectorsummarizeselects or aggregates the columns you care about. - How Many:
takeortoplimits the output.
Hands-on Lab Suggestion: Deploy a Windows VM and connect it to a Log Analytics Workspace using the Azure Monitor Agent. Intentionally cause some errors (e.g., try to start a disabled service). Then, go to the LAW and use basic KQL queries on the Event table to find the errors you just created. This solidifies the connection between an action on a resource and the resulting log entry.
Proactive Operations: Alerts and Action Groups
Monitoring data is useless if no one is looking at it. Alerts are the mechanism that proactively notifies you when Azure Monitor detects a problem in your infrastructure or application.
The alerting workflow is simple: A condition is defined in an Alert Rule. If the condition is met, the alert triggers an Action Group.
Choosing the Right Alert Rule Type
This is a classic exam topic. You’ll be given a scenario and asked to choose the most appropriate alert type.
| Alert Rule Type | Triggers On | Common Use Case | Real-World Example |
| Metric Alert | A metric value crossing a threshold | Performance issues (CPU, Memory, Response Time) | “Alert me if the average CPU on my VM is over 90% for 5 minutes.” |
| Log Alert | The result of a scheduled KQL query | Specific events, security threats, absence of data | “Alert me if a specific error ID appears in the Application Event Log.” |
| Activity Log Alert | An event in the Azure Activity Log | Administrative actions, service health issues | “Alert me if someone deletes a virtual machine in my production resource group.” |
Exam Pitfall: A common mistake is choosing a Metric Alert for something that requires log data. For instance, to be alerted when a specific Windows Service stops, you need a Log Alert. A Metric Alert can’t see inside the OS to that level of detail. The metric for “CPU percentage” is available, but the state of the “Print Spooler” service is an event, which is log data.
Action Groups: The Notification and Automation Engine
An Action Group is a reusable collection of notification preferences and actions.
- Notifications: Email, SMS, Push Notification, Voice Call.
- Actions: Trigger an Automation Runbook, a Logic App, an Azure Function, or send data to an ITSM tool (like ServiceNow).
Real-World Architecture: You can create powerful self-healing systems. For example, create a metric alert for “Server Response Time” on an App Service. If the response time exceeds 1 second, the alert triggers an Action Group. This Action Group doesn’t just email the admin; it also calls an Azure Function that automatically restarts the App Service to clear a potential memory leak. This moves you from simple notification to automated remediation.
Maintaining Resources: Backup and Update Management
Monitoring tells you when things are broken; maintenance prevents them from breaking or allows you to recover when they do.
Azure Backup and Recovery Services Vaults
Azure Backup is the native service for backing up Azure IaaS VMs, on-premises servers, SQL Server, SAP HANA, and Azure Files shares. The central management component is the Recovery Services Vault (RSV).
Key Concepts:
- Recovery Services Vault (RSV): An online storage entity in Azure used to hold backup data. It also manages backup policies and recovery points.
- Backup Policy: The heart of your backup strategy. A policy defines the schedule (when to take backups) and the retention (how long to keep them). This directly relates to your business’s Recovery Point Objective (RPO) and Recovery Time Objective (RTO).
- Item-Level Restore: For VMs, you can restore individual files and folders from a backup without having to restore the entire virtual machine disk. This is a huge time-saver.
Best Practice: Always deploy your Recovery Services Vault in the same region as the resources you are backing up to minimize latency and avoid cross-region data transfer costs. Use Geo-Redundant Storage (GRS) for your vault’s storage replication to ensure your backups are durable against a regional outage. To see where AZ-104 fits in the broader Microsoft Azure roadmap, check our Azure Certification Path.
Azure Automation Update Management
Keeping servers patched is a fundamental administrative task. Update Management, a feature of Azure Automation, provides a way to manage operating system updates for both Windows and Linux machines in Azure and on-premises.
Architectural Components:
- Automation Account: The container for your automation assets (runbooks, configurations, and the Update Management solution).
- Log Analytics Workspace: Update Management uses the LAW to store assessment data about which updates are needed and the results of update deployments.
- Hybrid Runbook Worker (for on-premises): Allows you to manage updates for servers outside of Azure.
The Process:
- Onboarding: You enable Update Management and onboard your VMs. This connects them to the LAW.
- Assessment: The solution periodically assesses the update status of all connected machines.
- Scheduling: You create a Scheduled Update Deployment to define which machines to patch, what types of updates to install (e.g., Critical, Security), and the maintenance window (when the patching can occur).
Common Mistake: Forgetting that Update Management relies on a Log Analytics Workspace. If you remove the LAW or the VM’s connection to it, Update Management will cease to function. The exam often tests these dependencies.
Frequently Asked Questions (FAQ)
I’m confused about Azure Monitor versus Log Analytics. Are they the same thing?
No, they are not the same, but they are deeply connected. Azure Monitor is the overarching brand for all monitoring services in Azure, while a Log Analytics Workspace is a specific environment within Azure Monitor used to store, retain, and query vast amounts of log data using the KQL language.
Think of it like this: Azure Monitor is the entire hospital. It has many departments. The Log Analytics Workspace is the hospital’s massive medical records archive. Doctors (you) go to the archive to query patient history (logs) to diagnose complex problems (troubleshooting). Other departments, like the ER (Metric Alerts), handle immediate, life-threatening issues (performance thresholds) without needing the full history.
For the AZ-104 exam, how much KQL do I really need to know?
You don’t need to be a KQL expert, but you must understand its purpose and be able to read basic queries. The key is to recognize the main keywords: where for filtering, summarize for aggregation, project for selecting columns, and render for visualization.
Pro Tip: Focus on interpreting what a query does. The exam is more likely to show you a query and ask, “What is the result of this query?” rather than asking you to write a complex query from scratch. For example, you should be able to look at Perf | where CounterName == "% Processor Time" | summarize avg(CounterValue) by Computer and know it’s calculating the average CPU per machine.
When should I use Azure Monitor Agent (AMA) instead of the old Log Analytics Agent (MMA)?
You should use the Azure Monitor Agent (AMA) for all new deployments, without exception. The legacy MMA agent was officially deprecated in September 2026. AMA is the future, offering more flexibility with Data Collection Rules (DCRs), improved performance, and cost savings through pre-ingestion filtering.
If a scenario requires sending different types of data from the same VM to different workspaces, AMA with DCRs is the only efficient way to do it. For any exam question posed in 2026, assume AMA is the preferred and correct solution for VM data collection.
What’s the real-world difference between a Recovery Services Vault and a Backup Vault?
A Recovery Services Vault (RSV) is the primary vault type for IaaS VM backups, SQL/SAP in Azure VMs, and Azure Files. A Backup Vault is a newer, more specialized vault designed for modern workloads like Azure Disks, Azure Blobs, and Azure Database for PostgreSQL.
For the AZ-104 exam, focus almost exclusively on the Recovery Services Vault. It’s the original and most common vault used for the core IaaS services that the exam covers heavily. Think of RSV as the general-purpose workhorse for traditional infrastructure backup. Also, see Microsoft Azure Certification Cost to understand exam-related expenses.
Can you explain Action Groups in simpler terms?
An Action Group is simply a reusable list of things to do when an alert fires. Instead of configuring email notifications and automation webhooks for every single alert rule, you define them once in an Action Group and then attach that group to multiple alert rules.
Think of it as a speed dial on your phone. You program “Mom” as speed dial #1. Then, whether you have good news or bad news, you just press #1. You don’t have to re-enter her number every time. An Action Group named “OnCall-Admins” might contain an email to a distribution list, an SMS to the team lead, and a webhook to create a PagerDuty incident. You can then attach this single “OnCall-Admins” group to your high-CPU alert, your server-down alert, and your security-breach alert.
How do I monitor costs in Azure?
While Azure Monitor tracks operational health, cost monitoring is primarily handled by Microsoft Cost Management and Billing. However, you can use Azure Monitor alerts to help control costs. For example, you can create an Activity Log alert that notifies you whenever a very expensive VM SKU (like a G-series) is deployed in your subscription. This provides an operational control to enforce cost governance.
Why is my VM not showing up in Update Management?
This is a common troubleshooting scenario. The most likely reasons are:
- Missing Agent: The VM does not have the Azure Monitor Agent (or legacy MMA) installed and reporting to the Log Analytics Workspace linked to your Automation Account.
- Incorrect Workspace: The VM is reporting to a different LAW than the one used by your Update Management solution.
- Firewall/NSG Issues: Network Security Groups or firewalls are blocking communication from the VM to the Azure Automation and Log Analytics service endpoints.
- Onboarding Failure: The solution failed to onboard the machine correctly. You can check the onboarding status in the Automation Account.
What’s the difference between Application Insights and Azure Monitor?
Application Insights is a feature within Azure Monitor. It is an Application Performance Management (APM) service specifically designed to monitor your live web applications. While Azure Monitor can tell you the CPU of the server hosting your app, Application Insights can tell you which line of code is running slow. It provides rich, developer-centric telemetry like server response times, dependency failures, and exception tracking. It feeds all its data into Azure Monitor Logs, so you can query it with KQL alongside your infrastructure data.
How can I back up a resource that isn’t supported by Azure Backup, like an Azure App Service?
Azure Backup has a specific scope. For Platform-as-a-Service (PaaS) offerings like Azure App Service or Azure Functions, you use the backup features built into those services. For an App Service, you navigate to the “Backups” blade within the App Service itself to configure scheduled backups of its files and connected database to a storage account. It’s a separate mechanism from the Recovery Services Vault.
Is there a way to see all important admin actions that have happened in my subscription?
Yes, absolutely. This is the primary purpose of the Azure Activity Log. It’s a platform log that provides insight into subscription-level events. It captures all control-plane actions, such as create VM, delete web app, or update network security group. You can view it directly, and more importantly, you can create Activity Log Alerts to be notified of critical actions, like the deletion of a production resource group.
My KQL query is running really slow. What am I doing wrong?
The most common reason for slow KQL queries is not filtering early enough. The KQL pipeline processes data from left to right. Always put your where clauses, especially those filtering on time (TimeGenerated), as early in the query as possible. This reduces the amount of data that subsequent operators like summarize or join have to process. Filtering 10 billion records down to 1 million first is much faster than trying to summarize 10 billion records.
What’s the best way to practice monitoring for the AZ-104 exam?
The best way is to build and break things. Create a free Azure account. Deploy a virtual machine and a simple web app. Then, use a tool to generate load on the VM’s CPU. Go into Metrics Explorer and see the spike. Create a Metric Alert for it. Next, stop a critical service inside the VM. Go into Log Analytics and write a KQL query to find the “service stopped” event. Create a Log Alert for that. Finally, configure Azure Backup for the VM, take a backup, then delete a file and perform an item-level restore. Hands-on experience is invaluable. You can also reinforce your preparation with our AZ-104 Exam Dumps.
Can I monitor my on-premises servers with Azure Monitor?
Yes. This is a key hybrid capability. You can install the Azure Monitor Agent on your on-premises Windows and Linux servers using Azure Arc-enabled servers. Azure Arc projects your on-prem machines as resources inside Azure. Once they appear in Azure, you can manage them just like an Azure VM—apply policies, collect logs with AMA and DCRs, and use Update Management to patch them.
How does Azure Service Health relate to Azure Monitor?
Azure Service Health is a separate service that provides information about the health of the underlying Azure platform itself—service issues, planned maintenance, and health advisories that could affect you. However, it integrates with Azure Monitor. You can create Activity Log Alerts that trigger when a Service Health notification is posted for your subscription. This is crucial for being proactively aware of Azure-side problems.
What’s a simple way to remember the main monitoring components?
Use this mental model:
- Collect: Azure Monitor Agent (AMA) and Data Collection Rules (DCRs) pull data in.
- Store & Analyze: Metrics for fast numbers, Log Analytics Workspace for deep logs (queried with KQL).
- Visualize: Dashboards and Workbooks for reporting, Metrics Explorer for interactive charting.
- Alert & Act: Alert Rules detect issues, Action Groups notify and automate the response.
Key Takeaways
- Azure Monitor is the central hub. Almost all monitoring services are part of or integrate with it.
- The future of data collection is the Azure Monitor Agent (AMA) managed by Data Collection Rules (DCRs). Legacy agents are being deprecated.
- Use Metrics for fast, numerical performance data (the “what”) and Logs for detailed, contextual event data (the “why”).
- Master the difference between Alert types: Metric (thresholds), Log (query results), and Activity Log (admin actions).
- A Log Analytics Workspace (LAW) is your queryable data lake for operational data. You must have a basic understanding of KQL to query it.
- Recovery Services Vaults are the core of IaaS backup. A Backup Policy (schedule + retention) is the key configuration object.
- Azure Automation Update Management depends on an Automation Account and a Log Analytics Workspace to patch VMs at scale.
Study Tips for Azure Administrator
- Get Hands-On: Theory is not enough. Use the Azure Free Tier to create resources and configure monitoring. Create an alert that sends an email to you. Back up a VM and restore a file. For a detailed comparison of Azure certifications, see AZ-104 vs AZ-204 and AZ-104 vs AZ-305
- Focus on Scenarios: Don’t just memorize what a service does. Ask “When would I use this?” The exam tests your ability to apply knowledge to solve a problem.
- Understand Dependencies: Know that Update Management needs a LAW. Know that AMA needs a DCR. The exam loves to test these connections.
- Draw the Architecture: Whiteboard the flow of data. A VM with AMA -> DCR sends data to -> a LAW. An Alert Rule queries -> the LAW and triggers -> an Action Group. Visualizing these connections will lock them in your memory.
Conclusion
Mastering the monitoring and maintenance domain of the AZ-104 is non-negotiable for becoming a competent Azure Administrator. These skills ensure the reliability and performance of the environments you so carefully build. By understanding the core pillars of observability, the roles of Azure Monitor, the new AMA/DCR agent model, and the critical maintenance tasks of backup and updating, you are well-equipped to tackle both the certification exam and the challenges of a real-world operational role. If you’re exploring multiple certifications, check our full list of All Microsoft Certifications and Highest Paying Microsoft Azure Certifications. For those comparing cloud providers, don’t miss AWS vs Azure Salary. Continue to practice, stay curious, and build on this foundational knowledge.
Start your preparation today with our complete Microsoft Exam Dumps and get access to AZ-104 Azure Virtual Networking resources for deeper learning.

