AZ-400 instrumentation strategy explained
Implement an instrumentation strategy is the smallest AZ-400 domain at 5-10%, but it closes the DevOps loop: after you deploy, how do you know it works? It covers configuring monitoring for a DevOps environment and analysing the metrics it produces. Expect a few questions, most of them about Application Insights, Azure Monitor Logs and basic Kusto Query Language (KQL).
Configure monitoring
Azure Monitor and Logs
Azure Monitor collects metrics (numeric, near real-time) and logs (records stored in a Log Analytics workspace). To integrate with DevOps tools you send telemetry to a workspace and act on it with alerts, dashboards and workbooks, and you can trigger actions in pipelines or chat tools through action groups.
Telemetry sources
| Source | Watches | Notes |
|---|---|---|
| Application Insights | Application requests, dependencies, exceptions, page views | Instrument the app with the SDK or auto-instrumentation; part of Azure Monitor |
| VM insights | VM performance and process dependencies | Uses the Azure Monitor Agent |
| Container insights | AKS clusters and containers | Node, pod and container metrics and logs |
| Storage and network insights | Storage accounts and networks | Ready-made views |
Application Insights adds concepts that scenario questions use: the application map (components and dependencies), availability tests (synthetic probes from several locations), live metrics, failures and performance blades, and distributed tracing across services using correlated operation IDs.
Monitoring in GitHub and pipelines
GitHub provides repository and organization insights and charts, and you can create alerts for failures of GitHub Actions workflows and Azure Pipelines runs, for example notifications to Teams or email, or a service hook that triggers an incident process. Pipeline health (failure rate, duration, flaky tests) is a monitoring subject in the pipelines domain too.
Analyse metrics
- Infrastructure indicators. CPU, memory, disk and network; know that a sustained high CPU on a VM and a memory leak in a container show up differently in metrics.
- Usage and performance. Request rate, response time, failure rate, user counts and dependency duration.
- Distributed tracing. Follow a single request through several services to find the slow or failing hop.
- Logs with KQL. You do not need to be an expert, but read simple queries:
requests
| where timestamp > ago(1h)
| summarize avg(duration), count() by name
| order by avg_duration desc
Know where, summarize ... by, project, order by, ago(), bin() and render.
| Question | Where to look |
|---|---|
| Which API operation is slowest? | Application Insights performance, or a requests KQL query |
| Why did one transaction fail across services? | Distributed tracing, end-to-end transaction view |
| Is the site reachable from other regions? | Availability test |
| Is a node running out of memory? | Container insights or VM insights metrics |
| Notify the team when a pipeline fails | Pipeline notification or service hook |
Common mistakes
- Reaching for VM insights when the question is about request flow.
- Using a metric alert when the signal exists only in logs. A log alert rule evaluates a KQL query.
- Forgetting that logs need a Log Analytics workspace, while platform metrics are collected automatically.
Example questions
Question 1. You need to be told when your public website cannot be reached from three different regions, even when no users are online. What should you configure?
- A. Live metrics stream
- B. VM insights
- C. A CPU percentage alert on the web server
- D. An Application Insights availability test with alerting
Show answer
Answer: D
Availability tests in Application Insights probe the endpoint from several locations on a schedule, regardless of real traffic, and can raise alerts. Live metrics show current activity, so it needs users. VM insights monitors machines, and a CPU alert cannot detect external reachability.
Want more questions like this? Full AZ-400 practice tests →
Question 2. You want to find the 10 slowest operations of a web app in the last hour using logs in the Log Analytics workspace. Which query operators are most appropriate?
- A. project and render only
- B. where, summarize avg(duration) by name, and order by
- C. summarize count() by timestamp
- D. render timechart with no filter
Show answer
Answer: B
Filtering by timestamp with where, calculating average duration per operation name with summarize, and ordering with order by (then taking the top results) answers the question. A query that only projects columns does not aggregate. Counting by a single timestamp does not rank by duration, and render alone only draws a chart.
Want more questions like this? Full AZ-400 practice tests →
Question 3. An AKS cluster hosts several microservices. You need pod and container CPU and memory metrics and container logs collected in a Log Analytics workspace. What should you enable?
- A. Container insights
- B. VM insights
- C. Storage insights
- D. Network insights
Show answer
Answer: A
Container insights collects node, pod and container metrics and logs for AKS into a Log Analytics workspace. VM insights targets virtual machines, not pods. Storage insights monitors storage accounts, and network insights monitors network resources.
Want more questions like this? Full AZ-400 practice tests →
Next
You have covered all five domains. See the exam tips, then take the practice test.