AZ-400 - Implement an Instrumentation Strategy (8% of the exam) - Section 5.1

Configure monitoring for a DevOps environment, including Azure Monitor, Application Insights, Container Insights, and alerts for GitHub Actions and Azure Pipelines.

Configure monitoring for a DevOps environment using Azure Monitor, Application Insights, Container Insights, and VM Insights to capture telemetry from applications and infrastructure. Set up alerts for GitHub Actions and Azure Pipelines so that build and deployment failures trigger notifications through the correct channels.

Azure MonitorApplication InsightsContainer InsightsVM Insightspipeline and Actions alerts

Practice question for this objective

Free sampleImplement an Instrumentation Strategymedium

A team using "GitHub Actions" wants every member who is watching a repository to be notified when a scheduled nightly workflow run fails, without standing up any external monitoring service or webhook receiver. Which native mechanism delivers these failure notifications?

  • AAn Azure Monitor activity log alert scoped to the repository's workflow, paired with an action group, which emails the watchers whenever the nightly GitHub Actions workflow run reports a failed status.
  • BA repository webhook delivering workflow run events to a self-hosted receiver that parses the payload and forwards a message to the watchers whenever a nightly workflow run finishes with a failure.
  • CA branch protection rule requiring the nightly workflow as a status check, so a failed run blocks merges and the resulting check failure message informs the watchers that the nightly run did not succeed.
  • DGitHub's built-in Actions notifications, which send the watchers their configured email or web notification when a workflow run they are subscribed to fails, with no external service required. Correct
Use GitHub's native Actions notifications to alert watchers on workflow run failures without external monitoring infrastructure. GitHub Actions integrates with the platform's notification system, so users watching a repository receive email or web notifications when a workflow run they follow fails, honouring their personal notification preferences. Azure Monitor cannot observe GitHub Actions run status, a webhook receiver demands external infrastructure, and branch protection status checks only gate merges, so none of those meet the no-external-service requirement.

Why A is wrong: Azure Monitor activity log alerts watch Azure resource operations and is tempting because it does alerting, but it has no visibility into GitHub Actions run status, so it cannot fire on the failure.

Why B is wrong: A webhook plus self-hosted receiver can detect failures but requires standing up and maintaining an external service, which directly violates the requirement to avoid any external receiver.

Why C is wrong: Branch protection status checks gate pull request merges, and a scheduled nightly run is not tied to a merge, so the rule neither evaluates that run nor notifies watchers of its failure.

Why D is correct: GitHub natively notifies users about Actions workflow run failures through their existing notification settings, delivering the failure alerts without any external monitoring service or webhook receiver.

See more AZ-400 practice questions, answers explained.

Exam traps in Implement an Instrumentation Strategy

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

  • Run a Kusto query over the requests table on a short time range and refresh it repeatedly so the most recent ingested request and failure rows appear as they arrive.

    Why it is wrong: Querying the requests table reflects ingested data and is tempting for recency, but ingestion and indexing add minutes of delay, so a refreshed query cannot deliver the roughly one-second view required to abort a rollout immediately.

  • Enable "VM Insights" on the AKS agent nodes so the platform collects guest operating system performance counters and a dependency map of the processes running across the cluster's worker machines.

    Why it is wrong: VM Insights instruments virtual machine guests and is tempting because AKS nodes are VMs, but it does not understand pods, containers, or controllers, so it misses the Kubernetes-aware metrics the team needs.

  • Pin individual metric and log query tiles to a shared Azure portal dashboard so each team sees the saved tiles, accepting that the tiles show fixed scopes that were set when each tile was pinned.

    Why it is wrong: A shared dashboard collects tiles and is tempting for a combined view, but its tiles are largely static snapshots without interactive parameters, so it cannot offer a dropdown that re-queries every chart for a chosen environment.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.