Microsoft AZ-204: Azure Monitoring, Diagnostics and DevOps Integration — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Monitor and Application Insights provide a unified, developer-focused observability stack for Azure applications. Application Insights collects application telemetry such as requests, dependencies, exceptions, and traces, while Azure Monitor aggregates metrics and logs across resources into a Log Analytics workspace and drives alerting and DevOps integrations. Mastering instrumentation choices, telemetry semantics, availability testing, Kusto Query Language (KQL), alerting with action groups, distributed tracing, and Infrastructure as Code with ARM templates ensures reliable, diagnosable, and automatable solutions.

Application Insights instrumentation and telemetry

Application Insights resources are identified for ingestion by either an instrumentation key or a connection string. The instrumentation key is the legacy single GUID used by SDKs to route telemetry. The connection string is the current recommendation; it includes the instrumentation key plus endpoint metadata (ingestion and Live Metrics endpoints) and allows routing to non-default endpoints (for sovereign or private clouds). Use the connection string in new code and configuration; it enables future endpoint changes without code redeployments. Within an App Service, enabling Application Insights at the platform level will populate the connection string into environment settings for auto-detected runtimes.

Instrumentation can be done via SDK or auto-instrumentation. The SDK approach (for example, Microsoft.ApplicationInsights.AspNetCore for .NET, applicationinsights for Node.js, and Application Insights Java agent) offers code-level control: custom events, metrics, and enriched telemetry via TelemetryInitializers and processors, including adaptive sampling. Auto-instrumentation (codeless attach) is available for App Service and some compute stacks and uses site extensions/agents to collect incoming requests, dependencies, and exceptions with no code changes. Use SDK instrumentation when you need custom events, business metrics, or explicit correlation in background jobs; use codeless attach for rapid, low-effort visibility or for lift-and-shift workloads. In both cases set the cloud role name to distinguish services in a microservices architecture and configure sampling carefully to balance fidelity and cost.

Application Insights emits several core telemetry types:

• Requests capture inbound operations (HTTP requests, function invocations), with duration, response code, and success.
• Dependencies capture outbound calls (HTTP, SQL, Azure SDK calls, queues), with target, type, duration, and success.
• Exceptions capture thrown errors, stack traces, and handled exceptions when explicitly tracked.
• Traces capture log messages; SDKs integrate with popular logging frameworks so logs and telemetry share correlation.
• Events capture custom, business-level occurrences via TrackEvent, supporting custom dimensions and counts.
• Metrics capture numeric measurements; you can track custom metrics for KPIs and inspect them in Metrics Explorer.

Distributed tracing in Application Insights hinges on correlation. Each end-to-end operation has an operation ID (trace ID in W3C terms) shared across related telemetry; each span has parent-child relationships enforced by propagation headers. Modern SDKs use the W3C Trace Context (traceparent, tracestate). Operation_Id in KQL ties Requests, Dependencies, Exceptions, and Traces for the same transaction. Ensure outbound HTTP clients propagate headers; for .NET, System.Diagnostics.Activity and the AI SDK handle this automatically. Dependency tracking instruments common clients (HTTP, SQL, Service Bus, Storage). When services cross boundaries (e.g., App Service to AKS), consistent propagation yields a single connected transaction map. For async and message-based flows, ensure the SDKs capture and flow correlation IDs in message metadata; most Azure SDKs do this by default.

Availability testing and synthetic monitoring

Availability tests validate external reachability and responsiveness from multiple geographies. The URL ping test issues HTTP requests at a configured frequency from multiple test locations and validates status codes, SSL health, and optional content match. Use retries and multiple locations to reduce false positives and configure alerts on test failures for actionable notifications.

Multi-step availability tests historically executed recorded sequences of HTTP requests with stateful cookies to verify workflows. Classic multi-step web tests have been retired; for multi-request or authenticated scenarios, implement synthetic tests by instrumenting your own client or service using the TrackAvailability API (or OpenTelemetry exporters) to emit AvailabilityTelemetry. This approach allows custom authentication, payloads, and domain-specific validation while retaining centralized reporting and alerting.

Custom TrackAvailability gives you control over:

• Test name, run location, and sequence identifiers for trend analysis and deduplication.
• Duration and success semantics based on your validations, not just HTTP status.
• Rich messages and custom dimensions for root-cause hints and correlation with backend telemetry.

Combine availability tests with backend dependency and request telemetry to quickly differentiate endpoint availability issues (network, DNS, TLS) from application failures (exceptions, timeouts) and downstream outages (SQL, external APIs). Tie availability test failures to action groups to drive incident workflows.

Azure Monitor data, KQL, and alerting with action groups

Azure Monitor ingests two primary data types: metrics and logs. Metrics are lightweight, numeric time series with near real-time ingestion and multi-dimensional slicing (e.g., by instance, API route). They are best for fast detection (CPU, memory, request rate, latency, availability) and support up to 93 days retention by default. Logs are structured, queryable records stored in a Log Analytics workspace and include Application Insights data, platform resource logs, and custom logs with configurable retention. Use Diagnostic settings to route platform metrics and resource logs to a workspace, Event Hub, or Storage for archival and analytics.

Kusto Query Language (KQL) powers exploratory analysis, dashboards, and log alerts. Core patterns include:

• Basic queries: Table | take 10 for quick sampling; always constrain time with where TimeGenerated >= ago(…) early for performance.
• Filtering and projection: Table | where Column == “Value” | project KeyColumns to reduce payload and focus analysis.
• Aggregation: summarize count() by bin(TimeGenerated, 5m), Dimension to compute rates, percentiles, or averages; use percentile() and make-series for time charts.
• Joins: join kind=inner or leftouter on correlation keys such as operation_Id to connect Requests with Dependencies or Exceptions; for cross-resource joins, ensure both send to the same workspace or enable cross-resource queries.
• Useful tables: requests, dependencies, exceptions, traces, availabilityResults for Application Insights; AzureDiagnostics and AzureActivity for platform logs; Perf and Heartbeat for VM insights.
• Best practices: project only needed columns, filter early, bin on reasonable intervals, and avoid expensive cross-joins on large windows unless necessary.

Alerting spans metrics and logs. Metric alerts evaluate metric thresholds in near real time, support dimensions and splitting by dimension, and can use static or dynamic thresholds (ML-based baselines). They are stateful and can fire and auto-resolve based on evaluation results, producing one notification when state changes. Log (scheduled query) alerts run KQL on a cadence and trigger on query results (number of matches or measure thresholds). Use log alerts when conditions depend on complex patterns across tables or require text analysis. Smart detection and anomaly alerts in Application Insights can highlight regressions without explicit thresholds.

Action groups define reusable response sets for alerts. Notification types include email, SMS, voice, and Azure mobile app push. Integrations include:

• Webhooks (v1 and v2) with Common Alert Schema for consistent payloads; set custom headers for authentication and route to incident systems (e.g., PagerDuty or custom receivers).
• Azure Functions, Logic Apps, and Automation runbooks for programmatic remediation and enrichment; use Logic Apps for flexible transformations and connectors.
• ITSM connectors (e.g., ServiceNow) to open incidents with mapped fields. Pair action groups with alert processing rules to suppress during maintenance, route by severity, or apply dynamic actions. For secure outbound webhooks, restrict receiver to Azure IPs or require signatures/headers and validate the Common Alert Schema properties such as Essentials.AlertRule and AlertContext.

ARM templates for monitorability and repeatable deployment

Azure Resource Manager (ARM) templates declaratively define resources and monitoring configuration as code. A template’s structure includes:

• $schema and contentVersion to identify the template version.
• parameters for externalized values (e.g., workspace names, locations, SKUs). Use secureString/secureObject for secrets.
• variables for computed values to avoid repetition.
• resources for declarative deployment of Application Insights, Log Analytics workspaces, alert rules, action groups, and diagnostic settings.
• outputs to emit values like Application Insights connectionString for downstream deployment stages.

Use linked or nested templates to compose complex deployments. A deployment resource (Microsoft.Resources/deployments) references a child template via templateLink (external URI) or embeds it inline. Pass parameter objects via parameters or parametersLink, define dependsOn for ordering, and reuse modules across environments. Examples of monitorability-by-default through ARM:

• Deploy a Log Analytics workspace and set workspaceResourceId outputs used by Application Insights resources (workspace-based mode).
• Create Application Insights (workspace-based) and output its connectionString; avoid exposing legacy instrumentation keys.
• Enable Diagnostic settings on resources (e.g., App Service, Key Vault, Storage) to stream logs and metrics to the workspace and/or Event Hub.
• Provision metric alerts (microsoft.insights/metricAlerts) with criteria and dimensions, and scheduled query alerts (microsoft.insights/scheduledQueryRules) with KQL, linking action groups by resource ID.
• Define action groups (microsoft.insights/actionGroups) with email/SMS and webhook receivers; parameterize addresses and endpoints for environment-specific routing.

Adopt conditions and copy loops for scalable deployments (e.g., apply diagnostic settings to a set of resource IDs). Use ARM functions such as resourceId, subscriptionResourceId, reference, concat, and guid to build dynamic references and stable names. Keep telemetry configuration consistent across services by centralizing role name conventions and sampling in app settings delivered via ARM or App Service configuration resources.

Practical Problem Scenario

Adobe needs end-to-end observability for a new multi-region media processing pipeline built on Azure App Service APIs and AKS microservices. They require fast detection of latency regressions, distributed tracing across services, proactive availability checks for public endpoints, and automated incident routing to their on-call system with infrastructure-as-code repeatability.

1. Instrument services with Application Insights using connection strings

• Configure each App Service and AKS workload to use the Application Insights connection string rather than legacy keys, ensuring correct ingestion endpoints and future-proof routing. Set cloud role names per service to enable clear filtering and maps. Choose SDK-based instrumentation in core APIs to emit domain events and metrics; enable codeless attach for auxiliary services to accelerate coverage. Why: Connection strings allow endpoint flexibility; SDKs provide custom telemetry while codeless attach keeps cost of adoption low.

2. Enable distributed tracing and dependency tracking

• Ensure outbound HTTP clients and Azure SDKs propagate W3C trace context; verify operation_Id continuity in KQL. For background message flows (Service Bus), confirm correlation is injected and extracted by the SDKs; supplement with TelemetryInitializers where custom headers are used. Why: Consistent trace propagation yields accurate end-to-end latency and failure attribution across microservices.

3. Implement availability tests and custom synthetic checks

• Configure URL ping tests for public APIs from multiple geographies with content match on a lightweight health endpoint. For authenticated flows (token acquisition and media submission), implement a synthetic client that calls the workflow and emits TrackAvailability results with run location and detailed messages. Why: URL pings provide fast external verification; TrackAvailability supports complex, authenticated business flows beyond basic pings.

4. Centralize data in a Log Analytics workspace and route platform logs

• Deploy a workspace and configure Diagnostic settings on App Services, AKS control plane logs, Key Vault, and Storage to stream logs and metrics into the workspace. Ensure Application Insights resources are workspace-based to unify queries. Why: A single workspace enables cross-service KQL, joining requests, dependencies, and platform logs for holistic investigation.

5. Create metric and log alerts with action groups

• Define metric alerts on request duration percentiles and availability by location with dynamic thresholds, splitting by cloud role name. Add scheduled query alerts that detect error spikes by operation name and correlate with dependency failures using a KQL join on operation_Id. Why: Metric alerts provide near real-time detection; log alerts capture complex patterns not expressible as simple thresholds.

6. Integrate incident response via action groups and webhooks

• Configure an action group with email for service owners, SMS for on-call leads, and a secure webhook to Adobe’s incident platform using the Common Alert Schema. Add a Logic App receiver to enrich payloads with recent KQL query results and topology metadata. Why: Multi-channel notifications reduce MTTA; webhook and Logic App enable automated ticketing and context-rich incidents.

7. Codify monitoring with ARM templates

• Author ARM templates to deploy the Log Analytics workspace, Application Insights (workspace-based), diagnostic settings, metric alerts, scheduled query alerts, and action groups. Parameterize environment names, regions, and contact points; output the Application Insights connectionString for downstream app configuration. Use linked templates for team-owned modules (platform vs. app). Why: Infrastructure-as-code ensures consistent, repeatable observability across dev, staging, and production and supports CI/CD.

8. Validate with KQL dashboards

• Build dashboards using KQL that summarize latency by service (summarize percentiles by bin and role), error rates joined to dependency targets, and synthetic availability by location. Incorporate time range filters and drill-through to traces and exceptions. Why: KQL provides flexible analysis and actionable visualizations for engineering and operations.

← Azure Caching · All domains

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →