Instrument, query, and alert on application behavior
Where it sits in the route
This module follows the application’s runtime, data, and integration paths. It teaches evidence boundaries before the learner reaches AZ-400 continuous feedback and deployment decisions.
Prerequisites and outcomes
Know request/response flow, dependencies, HTTP status codes, and basic time-series and log ideas. You should be able to distinguish a metric, log, and trace; instrument an application conceptually; query a signal; and connect an alert rule to a response action.
Concept sequence and relationships
An application or platform component emits telemetry to Application Insights and [[azure-monitor|Azure Monitor]]. Metrics show numeric trends, logs record events and properties, and distributed traces follow a request across dependencies. An availability test probes the externally reachable experience. An alert rule evaluates a signal against a condition; an action group routes notification or automation.
Instrumentation is not monitoring: instrumentation produces evidence, while monitoring collects and interprets it. An alert rule is not an action group: the rule decides that a condition is true, while the group decides what response to send. A missing trace can indicate instrumentation or sampling; a failed availability test can indicate DNS, TLS, ingress, or application behavior.
Worked scenario
An order API returns 500 responses. A request metric shows the spike, logs identify the exception, and a distributed trace identifies the slow database dependency. An external availability test confirms whether customers can reach the endpoint. The alert rule evaluates the error rate, and the action group pages the on-call team. Each signal has a different boundary and diagnostic value.
Conceptual checkpoint
For a latency spike, missing telemetry, and failed endpoint test, choose the first signal to inspect, name the likely boundary, and explain which condition should alert and how the response is routed.
Hands-on / what to try
Read a sample telemetry table and KQL query, predict the result after changing a filter, and map each alert to its action group. Restore the correct filter and remove test alert destinations. This is a static procedure and not live-verified.
Sources and re-audit
- AZ-204 monitoring objectives, skills measured 2026-01-14; checked 2026-08-31.
- Application Insights overview, checked 2026-08-31.
- Azure Monitor alerts, checked 2026-08-31.
Re-audit when telemetry collection, KQL, availability tests, alert rules, or action groups change.