Exam objective 6.2 requires you to know how to find problems in your Azure DevOps pipelines and fix them before they break your software releases. This is not about guessing what went wrong — it is about using the built-in tools Azure DevOps gives you to see exactly what happened, when it happened, and why it happened so you can get back to building.
Jump to a section
A simple way to picture Monitoring and Troubleshooting Azure DevOps
An elevator's control panel is a silent record-keeper.
Every time the doors open, every floor button pressed, every time the car hesitates for a split second too long, the panel notes it. When a tenant complains the elevator smells weird or stops too abruptly, the building manager doesn't just go by what the person said. She plugs a diagnostic laptop into the control panel and downloads the log. She sees that the doors have been cycling open and closed four times before fully closing, which matches a known sensor fault. She sees that the motor temperature spiked at 3 PM, exactly when the car got stuck for twelve seconds. She doesn't guess. She uses the recorded data to pinpoint the exact sensor or wiring issue. From the panel's point of view, the log is not a story. It is a precise, timestamped list of every signal and state change. The manager's job is to read that list, spot the anomaly — the repeated 'Door Obstruction' warnings — and trace it to the physical sensor that needs cleaning. The tenants feel safer because the manager doesn't wait for a breakdown. She watches the log trends and replaces the sensor before it fails completely."
Monitoring and troubleshooting Azure DevOps is the practice of watching your software delivery processes in real time and diagnosing failures when they occur. Imagine you have a set of automated steps — called a pipeline — that takes your code, tests it, packages it, and deploys it to servers. If that pipeline fails, you need to know why. Did a test fail? Did the server run out of memory? Did someone accidentally delete a critical file? Monitoring gives you a dashboard and alerts to tell you something is wrong. Troubleshooting is the detective work to find the exact cause.
Azure DevOps provides several tools for this. The most important is Azure Monitor, which is a cloud service that collects telemetry data — logs, metrics, and performance information — from your applications and infrastructure. Telemetry simply means data automatically sent from your software about how it is behaving. You can also use Application Insights, which is a specific part of Azure Monitor that tracks the performance of your live web applications, showing you which pages are slow, which database queries are failing, and which parts of your code cause errors.
Another key tool is Azure Pipelines, which runs your builds and releases. Within Pipelines, you can view a detailed log for every step of every run. A log is a text file that records every action the pipeline took, along with timestamps and error messages. If a build fails, the first thing you do is open the log to see the exact error.
You also have Azure Boards, which tracks work items like bugs and tasks. When you find a problem, you can create a bug work item to track the fix. Integration between Boards and Pipelines means a failed pipeline can automatically create a bug.
Why does this matter? Before DevOps, teams would find out about a problem only when a customer called to complain. By that time, the code had been broken for hours or days. Monitoring gives you near-instant awareness. Troubleshooting gives you a structured way to diagnose without guessing. For the AZ-400 exam, you need to understand the difference between monitoring (watching for problems) and troubleshooting (finding the root cause). You also need to know which tools map to which scenario. For example:
If a web app is responding slowly to users, use Application Insights to check server response times and database query durations.
If a build pipeline fails, use Pipeline logs to see the exact step that errored.
If you want to be alerted when a pipeline fails, set up an alert rule in Azure Monitor that triggers an email or a webhook.
If you need to analyse historical trends to see which tests fail most often, use the Analytics views in Azure DevOps.
A critical concept here is 'root cause analysis'. This is the method of digging past the symptom to find the underlying cause. For instance, a symptom might be 'the web app crashes at 3 PM every day'. The root cause might be 'a memory leak in the image processing library that spikes after two hours of steady traffic'. Troubleshooting involves correlating timestamps from Application Insights with deployment records to find the version that introduced the leak.
The exam also tests your knowledge of 'continuous monitoring', which means integrating monitoring into your pipeline itself. For example, you can configure your pipeline to run load tests and if response times exceed a threshold, the pipeline fails and stops the deployment. This is called 'gating' — using monitoring data as a pass/fail condition.
Finally, you must understand that monitoring and troubleshooting are not one-time activities. They are continuous loops. You monitor, you detect a problem, you troubleshoot it, you fix the code or configuration, you deploy the fix, and then you monitor again to confirm the fix works. This loop is the heart of a resilient DevOps practice.
Detect the Problem
Whether through an Azure Monitor alert, a dashboard metric crossing a threshold, or a user complaint, you first become aware that something is wrong. This step is about awareness — it tells you to start investigating.
Identify the Affected Component
Use Azure Monitor or Application Insights to narrow down which service, endpoint, or pipeline run is impacted. Look at the 'Application Map' in Application Insights to see the dependencies — which database, which API, which external service — that are failing.
Examine the Logs
Open the relevant logs. If it is a pipeline failure, open the Pipeline logs from the failed run. If it is a runtime error, use the 'Transaction Search' in Application Insights to find exceptions. Read the error message and stack trace to identify the code file and line number.
Determine the Root Cause
Correlate the log information with recent changes. Check if the error started after a recent deployment by looking at the release history in Azure Pipelines. Use Log Analytics queries to see if the error pattern matches a specific time window or user geography.
Create a Bug and Assign It
In Azure Boards, create a bug work item with the exact error message, stack trace, steps to reproduce, and links to the failing pipeline run. Assign it to the responsible developer. Use the 'Create work item' action from an alert to automate this step in the future.
Apply the Fix and Test
The developer writes a code fix and submits a pull request. The pipeline automatically runs existing tests plus any new tests you added to cover the bug scenario. Confirm that the pipeline passes before deploying to production.
Deploy and Monitor the Fix
Deploy the fixed version using a release pipeline. After deployment, monitor Application Insights to ensure the error rate drops to normal levels. If the alert does not fire again, the fix is successful.
Post-Incident Review
Hold a quick retrospective. Update your alert thresholds if they were too loose. Add new test cases. Update your runbook — a document that describes how to handle this kind of failure in the future — so the next person can resolve it faster.
An IT professional working at a medium-sized e-commerce company uses monitoring and troubleshooting tools daily. It is not theoretical — it is how they keep the online shop running during high-traffic sales. Here is a realistic scenario.
The company deploys a new feature every Thursday. One Thursday, after deployment, the monitoring dashboard shows a spike in '500 Internal Server Error' responses on the payment page. The IT professional — let us call her Priya — receives an email alert from Azure Monitor at 2:37 PM.
Priya opens the Azure Portal and navigates to Application Insights. She looks at the 'Failures' tab. She sees that the payment endpoint is returning 500 errors for about 15 percent of requests. The error message says 'NullReferenceException: Object reference not set to an instance of an object.' That is a software bug — the code is trying to use an object that does not exist.
Next, she opens the specific transaction in Application Insights and looks at the 'End-to-End Transaction Details'. This shows her the exact code file and line number where the exception occurred. It points to a method called 'CalculateTax' in a file called 'OrderService.cs'. She can see that the code is trying to access a property on a variable that is null — meaning the code expected a value that was not provided by the new feature.
Rather than guessing, Priya opens Azure Pipelines and finds the build that was deployed at 2:00 PM. She opens the release log and confirms that the code that was deployed matches the version containing the buggy 'CalculateTax' logic. She also looks at the test results from that pipeline run. She notices that the unit test for 'CalculateTax' passed — but the test never checked for a null input. That is a test coverage gap.
Priya then opens Azure Boards and creates a bug work item titled 'NullReferenceException in CalculateTax when order has no shipping address'. She links it to the failed pipeline run. She then assigns the bug to the developer who worked on the tax logic. The developer fixes the code by adding a null check, and Priya reviews the pull request.
Before deploying the fix, Priya creates a new alert rule in Azure Monitor: if the payment endpoint returns more than 5% 500 errors in any 5-minute window, send an email to the on-call team. This ensures they catch it faster next time. She also adds a new unit test to the pipeline that explicitly tests for null inputs in 'CalculateTax'.
Finally, Priya uses Azure Dashboards to display key metrics: error rate, average response time, and test pass rate. She shares the dashboard with her team so everyone can see the health of the system. The entire process — from alert to fix to deployment — takes about 45 minutes. The team learns from the incident and strengthens their tests. This cycle of monitoring, troubleshooting, fixing, and improving is what the AZ-400 exam expects you to understand and implement.
The AZ-400 exam tests your ability to apply monitoring and troubleshooting concepts in specific scenarios. You will not be asked to memorise tool names in isolation. Instead, the exam gives you a scenario — for example, 'Your pipeline fails only on Fridays. What tool do you use to find out why?' — and asks you to choose the correct tool or action.
Here are the exact concepts the exam focuses on:
- Application Insights is one of the most tested services. You must know it is used for monitoring live applications — not for build logs. Traps often ask you to use it to diagnose a failed build. That is wrong. Use Pipeline logs for build failures, Application Insights for runtime errors.
- Azure Monitor Alerts and Action Groups. The exam tests your ability to create an alert that triggers an action — sending an email, running a webhook, or calling an Azure Function. A common trap is asking you to configure an alert on 'average CPU' when the real answer is 'error rate' or 'failure count'. Read the question carefully.
- Log Analytics is part of Azure Monitor that lets you run complex queries across logs. The exam may ask you to write a simple Kusto Query Language (KQL) query to find errors in a specific time range. You do not need to be a KQL expert, but you must recognise the structure: 'traces | where timestamp > ago(1h) | where severity == 3'.
- Continuous monitoring concepts: The exam loves scenarios where your pipeline uses monitoring data to decide whether to release. This is called 'quality gates'. For example, 'You want your pipeline to stop deployment if the error rate exceeds 2%. Which tool do you use?' Answer: Azure Monitor, combined with a pipeline gate that checks a metric.
- Retention and logging levels. The exam tests that you know how long logs are kept by default and how to change it. For example, pipeline logs are kept for 30 days by default. You can change retention on a per-pipeline basis.
- Troubleshooting common pipeline failures. The exam presents error messages — 'The job was cancelled because it timed out', 'The agent is offline', 'The artifact was not found'. You must know the most likely cause and the first step to take. For example, if an agent is offline, check if the self-hosted agent machine is running or if the PAT token has expired.
- Integration with Azure Boards. When a monitoring alert fires, you can automatically create a work item in Azure Boards. You must know how to configure this using the 'Create a work item' action in an action group.
The most common trap on the exam is confusing monitoring with troubleshooting. Monitoring is about dashboards, alerts, and metrics that tell you something is wrong. Troubleshooting is about logs, traces, and debugging to find the exact cause. If a question asks 'What should you use to find the line of code that caused a NullReferenceException?', the answer is Application Insights end-to-end trace details. If it asks 'What should you use to see how many errors occurred in the last hour?', the answer is Azure Monitor metrics or a Log Analytics query.
Finally, the exam tests your understanding of actionable alerts. An alert is not useful if it just says 'Error rate is high'. It must include enough context — the affected service, the time window, the severity — that someone can act on it immediately. The exam may ask you to design an alert rule with the right dimensions (like 'application name' and 'region') so it is specific enough not to be noise.
Monitoring uses dashboards and alerts to detect problems before users notice; troubleshooting uses logs and traces to find the root cause after a problem is detected.
Application Insights is the tool for diagnosing runtime errors in live applications, while Pipeline logs are for diagnosing failed builds and releases.
An alert should include enough context — service name, region, and severity — to be actionable without requiring extra investigation.
Quality gates in a pipeline can use Azure Monitor metrics to stop a deployment if error rates exceed a threshold.
Pipeline logs are retained for 30 days by default; always check retention policies before relying on historical data for troubleshooting.
Creating a bug work item from an alert automates the transition from detection to fixing, reducing manual triage time.
Kusto Query Language (KQL) in Log Analytics lets you query logs by time, severity, and message patterns to find specific failures.
A failed pipeline log should be your first stop for troubleshooting, not re-running the pipeline.
These come up on the exam all the time. Here's how to tell them apart.
Application Insights
Monitors live runtime behaviour of applications after deployment.
Provides distributed tracing and dependency mapping.
Used for diagnosing runtime exceptions and performance issues.
Pipeline Logs
Records actions inside the build or release pipeline during execution.
Provides a sequential text log of every command run.
Used for diagnosing failed builds or release steps.
Proactive Monitoring
Involves setting up dashboards and alerts to detect issues early.
Aims to catch problems before users are affected.
Uses metrics like response time and error rate thresholds.
Reactive Troubleshooting
Begins after a problem is already detected.
Focuses on finding the root cause through logs and traces.
Uses tools like Application Insights search and Pipeline log analysis.
Azure Monitor Alerts
An alert is a notification that a condition has been met (e.g., error rate > 5%).
Alerts can trigger emails, webhooks, or actions.
Alerts are not tracked as work items unless you configure them to create a bug.
Azure Boards Bugs
A bug is a formal work item in Azure Boards that tracks a defect.
Bugs have fields like severity, priority, and assignment.
Bugs are linked to pipeline runs and pull requests for traceability.
Log Analytics (KQL)
Allows custom queries across all logs from multiple Azure resources.
Requires writing Kusto Query Language queries.
Best for advanced analysts who need to correlate multiple data sources.
Transaction Search (Application Insights)
Provides a searchable interface for a single application's telemetry.
Does not require writing custom queries; uses filters and time ranges.
Best for quickly finding a specific exception in one application.
Mistake
Monitoring and troubleshooting are the same thing: both just mean looking at logs.
Correct
Monitoring is proactively watching metrics and alerts to know when something is wrong. Troubleshooting is the reactive process of investigating a specific problem after it has been detected. They use different tools in Azure DevOps: dashboards and alerts for monitoring; logs and traces for troubleshooting.
The terms are used loosely in casual conversation, so beginners assume they are interchangeable. The exam treats them as distinct, so mixing them up loses marks.
Mistake
If a pipeline build fails, the best way to debug is to re-run the pipeline and watch it live.
Correct
The correct approach is to open the logs from the failed run. Re-running wastes time and may not reproduce the exact failure. The logs contain the exact error message and timestamp, which is the fastest way to diagnose.
In many other contexts, 'just try again' is a common first reaction. Beginners often do not realise that pipeline logs are immutable records of what happened.
Mistake
Application Insights is only for web applications; it cannot be used for background jobs or APIs.
Correct
Application Insights supports many types of applications, including console apps, background services, and serverless functions like Azure Functions. Any application that sends HTTP telemetry can be monitored with it.
The name 'Application Insights' and its focus on web apps in early documentation give the impression it is limited, but it is actually a general-purpose monitoring service.
Mistake
Once you set up an alert, you do not need to tune it; the default thresholds are fine.
Correct
Default alert thresholds are generic and often cause alert fatigue — too many false positives. You should customise thresholds based on your application's normal behaviour, such as average response time or error rate baseline derived from historical data.
Default settings give a false sense of security. Beginners do not realise that poorly tuned alerts are worse than no alerts because people start ignoring them.
Mistake
Logs are automatically retained forever in Azure DevOps.
Correct
Pipeline logs have a default retention of 30 days. You can configure up to 365 days per pipeline. Other logs like Application Insights have configurable retention too, but none are infinite unless you explicitly set them to store in a Log Analytics workspace with a long retention policy.
Beginners assume cloud services keep everything forever because local computers often do not delete logs automatically. The exam tests this exactly because it is a common blind spot.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Monitor is the broad platform that collects logs and metrics from all Azure resources. Application Insights is a specific feature of Azure Monitor focused on monitoring live applications — it gives you detailed telemetry on requests, exceptions, and dependencies.
Go to Azure Pipelines, select the failed run, and click on the job that failed. Then open the log for that job. The log shows every command that ran and the exact error message with a line number.
Yes. Create an alert rule in Azure Monitor that watches the 'Failed pipeline runs' metric. In the action group, add an 'Email' action to send a notification to your team list.
A quality gate is a checkpoint in your release pipeline that checks a condition — like a metric from Azure Monitor — and not let the release proceed if the condition is not met. For example, 'block deployment if error rate > 2%' is a quality gate.
By default, pipeline logs are kept for 30 days. You can change retention to up to 365 days in the pipeline settings under 'Retention policies'.
A runbook is a written document that describes the exact steps to follow when a specific type of incident occurs. It helps anyone on the team resolve the problem quickly without having to figure out the steps from scratch.
You've finished Monitoring and Troubleshooting Azure DevOps. Continue through the AZ-400 study guide to build a complete picture of the exam.
Done with this chapter?