Microsoft AZ-400: Monitoring, Observability and Feedback — Study Guide
Part of the Microsoft DevOps Engineer Expert AZ-400 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.
Overview
Modern DevOps teams treat monitoring, observability, and feedback as a continuous loop that informs engineering, operations, and product decisions. In Azure, telemetry flows from applications and infrastructure into Azure Monitor and Log Analytics, where it is queried, correlated, and visualized. Distributed tracing ties services into end-to-end transactions, while alerting and on-call integrations drive fast remediation. Azure DevOps dashboards, work item analytics, and experimentation close the loop by feeding insights back into planning and delivery. This section provides the depth required to design an integrated observability stack that delivers actionable feedback at every stage.
Telemetry, Tracing, and Azure Monitor
Application Insights is the application performance monitoring (APM) component of Azure Monitor. Instrumentation is added via:
- SDKs and auto-instrumentation: .NET/.NET Core, Java, JavaScript, Node.js, Python, and the Application Insights Agent for .NET and Java. Use a connection string and set cloud_RoleName to distinguish components.
- Telemetry initializers and processors: Add or mutate properties (e.g., tenantId) and filter PII before emission.
- Custom telemetry: TrackEvent for business actions, TrackMetric for numeric KPIs, TrackException for error contexts, and TrackDependency for external calls you need to model explicitly.
Telemetry types include requests, dependencies (HTTP, SQL, Azure SDKs), traces, exceptions, page views, page load performance, availability test results, custom events/metrics, and live metrics. Sampling controls volume and cost while preserving signal: SDK adaptive sampling automatically tunes rates per type to maintain target throughput and correlation; fixed-rate sampling provides deterministic sampling for compliance. Favor SDK-side sampling so downstream systems never process dropped items. Maintain sticky sampling for end-to-end trace integrity.
Distributed tracing provides end-to-end transaction visibility. Application Insights implements the W3C Trace-Context standard (traceparent/tracestate), automatically propagating correlation IDs across HTTP; propagate context through async boundaries and custom protocols to avoid broken traces. Dependency tracking auto-collects common outbound calls; emit custom dependencies for message queue hops or nonstandard RPCs to complete the call graph. App Map and Transaction Search visualize cross-service flows, latencies, and failure hotspots. For front-end to back-end correlation, enable JavaScript SDK and ensure server-side correlation headers are accepted to measure true page load times and user journeys.
Azure Monitor unifies platform and application telemetry:
- Metrics: Multi-dimensional, near real-time (one-minute granularity or better). Use metric alerts with static or dynamic thresholds for fast, low-latency detections.
- Logs: Semi-structured telemetry in a Log Analytics workspace, queried with KQL for deep analysis and anomaly hunting.
- Alerts: Metric, log, and activity log rules route to action groups. Use dynamic thresholds, multi-resource targeting, and common alert schema for consistent handling.
- Action groups: Email/SMS/voice, push notifications, webhooks (including PagerDuty/OpsGenie), ITSM connectors, Logic Apps, Azure Functions, and Automation runbooks for remediation.
- Diagnostic settings: Configure each Azure resource to stream platform metrics/logs to Log Analytics, Azure Storage (for archival), and Event Hubs (for SIEM ingestion). Ensure consistency with policy-driven deployment.
Querying and Analytics with Log Analytics (KQL)
A Log Analytics workspace is the query and governance boundary for logs. Plan by environment and data sovereignty: separate workspaces for prod vs non-prod can simplify RBAC and retention policies; centralization eases cross-service correlation. Data sources include Azure Diagnostics (platform logs/metrics), VM agents (Syslog/Windows events, performance counters), Container Insights/AKS, Application Insights component logs (unified under Azure Monitor Logs), Azure AD sign-ins, custom logs via ingestion APIs, and Data Collection Rules for precise stream routing and transformation.
Kusto Query Language (KQL) is optimized for time-series and telemetry analytics:
- Core operators: where (filter), project (select), extend (derive), summarize by (aggregate), join/union (correlate), parse/parse_json (extract), mv-expand (arrays), make-series and bin for time bucketing, render for charting.
- Patterns: Error budget burn (time-weighted failure rates), p50/p95 latency distributions, dependency outlier detection, request success rate vs traffic, and anomaly detection using series_decompose_anomalies for seasonality-aware alerts.
- Governance: Saved queries and functions promote reuse; RBAC and table-level access restrict sensitive datasets.
- Cross-resource and cross-workspace: Use workspace(“workspaceNameOrId”).Table and the workspaces() function to combine datasets across environments and subscriptions; use resource() for cross-resource joins. Apply let bindings and materialize() to control performance on large joins.
Visualization and Agile Feedback in Azure DevOps
Dashboards in Azure DevOps communicate both operational and process health. Team-level dashboards focus on a team’s backlog, iterations, and WIP; project-level dashboards surface cross-team and portfolio views. Widgets include Sprint Burndown, Burnup, Velocity, Cumulative Flow Diagram (CFD), Cycle Time, Lead Time, Work Item Chart/Query Results, Build/Release summaries, and Markdown for runbooks and SLO status. Secure widgets with dashboard permissions and scope queries tightly to teams/areas to avoid cross-team leakage.
Boards queries (via the query builder or WIQL) power many widgets. Parameterize queries by team area path/iteration for reuse; prefer Analytics-based widgets when available for accuracy and performance. Key flow metrics:
- Cycle time: Elapsed time from Active (in progress) to Done; use the Cycle Time widget to track execution efficiency.
- Lead time: Elapsed time from creation/commitment to Done; signals total system delay as perceived by customers.
- Throughput: Items completed per time interval; compare to WIP policies to detect bottlenecks.
- Cumulative Flow Diagram: Visualizes queue sizes by state over time; widening bands expose constraints and context-switching. For sprint tracking, use Burndown (remaining work trend toward zero) and Burnup (total scope vs completed, resilient to scope change). Velocity reports the average completed effort per sprint and informs capacity planning; aggregate only like-for-like estimation units across teams.
Where product analytics is needed, connect Azure DevOps Analytics to Power BI to blend delivery metrics with operational telemetry (e.g., lead time vs defect escape rate) to prioritize improvements.
Reliability, Alerting, and Continuous Feedback
SLI/SLO/SLA establish reliability as a first-class feature:
- SLIs: Quantitative measures of user experience, e.g., request success rate, p95 latency, availability of critical endpoints, or task completion rate in the UI.
- SLOs: Targets over a window, e.g., 99.9% monthly availability or p95 < 300 ms. Tie SLOs to user journeys, not infrastructure.
- Error budgets: 1 − SLO; govern release risk, rollback criteria, and incident response. Implement burn-rate alerts (e.g., 2x and 14x budget burn) using KQL or metric alerts for both fast and slow breaches.
- SLAs: External commitments to customers; typically looser than SLOs and include penalties; drive but do not dictate engineering guardrails.
Alerting and on-call:
- Use metric alerts for latency-sensitive conditions; use log alerts for complex predicates (e.g., multi-signal correlation or anomaly scores).
- Reduce alert fatigue with deduplication (alert processing rules), dynamic thresholds, severity tuning, and auto-suppression during planned maintenance.
- Integrate with PagerDuty/OpsGenie via action group webhooks using the common alert schema; map alert correlation keys for incident dedup and define escalation policies per service.
- Automate remediation with Azure Automation runbooks, Functions, or Logic Apps (e.g., scale-out on queue depth, recycle a failing instance, toggle a feature flag). Record every auto-action as a custom event in Application Insights for auditability.
Continuous feedback and experimentation:
- A/B and gradual rollouts: Use Azure Front Door or Traffic Manager for traffic-splitting at the edge, or implement feature flags with Azure App Configuration Feature Manager for per-user or cohort-based rollout. Guard code paths with flags and collect event telemetry per variant.
- User telemetry: Emit TrackEvent with feature flag state, user properties (non-PII), and scenario identifiers. Analyze funnels, user flows, retention, and cohort performance in Application Insights to validate hypotheses.
- Feature usage analytics: Build dashboards that track DAU/WAU/MAU, feature adoption, and conversion metrics. Feed outcomes into backlog prioritization. Use Azure Pipelines gates to block production deployment when staging SLI baselines fail or experiment KPI regressions are detected.
Practical Problem Scenario
Spotify needs to improve end-to-end visibility and feedback for its podcast ingestion and playback services deployed on Azure Kubernetes Service (AKS) and Azure App Service APIs. Incidents are detected late, and product teams lack trustworthy adoption metrics for new playback features.
- Instrument and correlate application telemetry
- Add Application Insights SDKs to .NET and Node.js services; enable the Application Insights JavaScript SDK on web clients. Configure cloud_RoleName and connection strings; enable W3C trace-context propagation across microservices and message queues. Why: Ensures consistent correlation IDs and distributed tracing for complete transaction visibility from browser to services and dependencies.
- Stream platform diagnostics to Log Analytics
- Apply diagnostic settings via Azure Policy to all AKS clusters, App Service plans, Application Gateways, Cosmos DB, and Storage accounts, routing to a central prod workspace with 90-day retention and archive to Storage. Why: Guarantees uniform coverage of platform logs/metrics for KQL correlation and cost-effective long-term retention.
- Define SLIs, SLOs, and error budgets
- SLIs: p95 API latency, request success rate, ingestion pipeline throughput, and player start success.
- SLOs: 99.95% monthly success, p95 playback start < 300 ms, ingestion lag < 2 minutes.
- Create KQL-based error budget burn-rate alerts (fast/slow) and metric alerts for latency with dynamic thresholds. Why: Converts business outcomes into measurable, actionable reliability targets with timely alerts.
- Build actionable alerts and on-call integration
- Create Azure Monitor alert rules with smart grouping; route to an action group that triggers PagerDuty via webhook using the common alert schema. Attach Azure Automation runbooks to auto-scale on queue depth and restart unhealthy pods. Why: Reduces MTTA/MTTR through reliable paging and safe, auditable auto-remediation.
- Establish dashboards for engineering and product
- Azure DevOps team-level dashboards: Cycle Time (Active→Done), Lead Time (Created→Done), CFD, Velocity, and Sprint Burndown for squads. Project-level dashboards: Burnup for releases, cross-team throughput, and SLO status via Markdown/Analytics widgets. Why: Gives squads execution insight while providing leadership with portfolio and reliability health.
- Implement experimentation and usage analytics
- Use Azure App Configuration feature flags to gradually roll out a new “Smart Skip Silence” feature. Split cohorts with Front Door rules for A/B at the edge where needed. Emit TrackEvent with featureFlagState, user cohort, and outcome metrics. Why: Safely validates impact while capturing high-fidelity user telemetry for evidence-based decisions.
- Enforce release quality with gates
- In Azure Pipelines, add gates that query Application Insights/Log Analytics for staging KPIs (p95 latency, failure rate, experiment variant performance). Fail gates if baselines or SLO-aligned thresholds are not met. Why: Prevents regressions from reaching production and aligns deployment decisions with reliability and product KPIs.
← Testing Strategy and Quality Engineering · All domains · Package Management and Artifact Management →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →