Where AZ-400 sits on the Azure certification map

The Azure certification track has three tiers: Fundamentals (AZ-900), Associate (AZ-104, AZ-204, and others), and Expert (AZ-305 Solutions Architect Expert, MS-102 M365 Administrator Expert, and AZ-400 DevOps Engineer Expert). AZ-400 is the only Expert cert that branching from two Associate tracks — you can arrive via the administrator path (AZ-104) or the developer path (AZ-204), reflecting that DevOps in practice is a discipline that bridges infrastructure operations and application development rather than belonging purely to either.

The distinction in job market terms is significant. AZ-104 alone covers platform administration; AZ-204 covers application development. AZ-400 certifies the engineer who sits at the intersection — the person who builds the pipeline that takes code from commit to production and maintains the reliability and security of that delivery system. In 2026, Azure DevOps Engineer Experts holding AZ-400 average $135k–$175k in North American markets, with senior platform engineering and DevSecOps roles at cloud-native enterprises reaching $180k–$210k. Enterprise-scale organisations running large Azure footprints increasingly require AZ-400 for lead DevOps and cloud platform engineer roles, and the cert appears on DoD contractor job postings approved under DoD 8140.

The five exam domains

Domain 1 — Configure Processes and Communications (~10–15%)

The lightest domain by weight but foundational to the exam’s premise: effective DevOps is as much about the organisational process layer as the tooling layer. This domain tests:

  • Azure DevOps Boards configuration: work item types, fields, and process templates (Agile, Scrum, CMMI). Area paths and iteration paths create the two-dimensional coordinate system that maps work items to product areas and time-boxed sprints. The exam tests how to configure a Board to support a large team with multiple feature teams sharing a single Azure DevOps organisation — the answer involves org-level vs project-level settings, team-level area path ownership, and inherited vs customised process templates.
  • Agile planning and metrics: sprint velocity, cumulative flow diagrams (CFD), and cycle time / lead time as diagnostic metrics for delivery health. The exam presents a scenario (rising cycle time, flat velocity, growing WIP) and asks which metric and corrective action addresses the stated symptom. CFDs in particular — showing the width of in-progress bands expanding over time — are the canonical signal for WIP accumulation that is not visible in sprint velocity alone.
  • Communication and feedback loops: integrating Azure DevOps notifications with Teams and Slack via service hooks; configuring dashboards and widgets (build history, deployment frequency, work item query results) that give stakeholders visibility into delivery flow without requiring direct access to pipeline logs. The exam tests dashboard configuration as the answer when a scenario asks how to give a non-technical product owner real-time visibility into release health.
  • Inner-source practices: applying open-source collaboration patterns (fork model, pull request reviews, discoverability via README and CODEOWNERS) within an enterprise Azure DevOps organisation. Inner-source is the exam answer when a scenario describes a large organisation where multiple teams duplicate infrastructure code because consuming other teams’ work is too high-friction — the solution is a discoverable, well-documented shared repository with a defined contribution process, not a monorepo or a centralised platform team that becomes a bottleneck.

Domain 2 — Design and Implement Source Control (~15–20%)

Source control strategy is higher-stakes than most engineers assume. A poorly chosen branching model becomes a merge-conflict tax the entire team pays on every release. This domain tests:

  • Branching strategies: Trunk-based development (all engineers commit to a single main branch or short-lived feature branches that merge within a day or two; enables true continuous integration but requires strong test coverage and feature-flag discipline to hide incomplete work from production). GitHub Flow (feature branch → pull request → main; simple, works well for teams deploying continuously from main). GitFlow (main + develop + feature/release/hotfix branches; higher overhead, suited to teams with explicit versioned release cycles — the exam presents GitFlow as the correct answer for a regulated team that must maintain multiple simultaneous release versions but notes its complexity as a downside). The exam maps the stated deployment cadence and team structure to the correct branching model.
  • Branch policies and protection rules: Azure DevOps branch policies require a minimum number of reviewers, pass build validation, and prevent direct commits to protected branches. GitHub branch protection rules add required status checks and required code owners review. The exam tests CODEOWNERS files as the mechanism that automatically assigns reviewers based on which directories a PR modifies — ensuring security-sensitive paths always get a security team review without requiring the PR author to remember to add them manually.
  • Pull request quality gates: linked work items (ensuring every change is traceable to a tracked requirement), comment resolution requirements (blocking merge until all review threads are resolved), and auto-complete policies that merge only after all checks pass. The exam presents a scenario where hotfixes bypassed review and caused a production incident, and asks which combination of branch policies prevents it from recurring.
  • Secrets management in source control: .gitignore patterns to exclude secrets files from tracking; git-secrets or Azure DevOps Defender for DevOps secret scanning to detect leaked credentials before they leave the developer’s machine; pre-commit hooks as the first enforcement layer. The exam tests the sequence: pre-commit hook → pipeline secret scan → Azure Key Vault reference — not storing any secret value in the repository at any stage, not even encrypted. Rotating a leaked secret that was committed to history requires rewriting git history (git filter-repo) and rotating the credential value — prevention is the exam emphasis.
  • Large file storage: Git LFS (Large File Storage) offloads binaries, datasets, and build artefacts to a separate object store while keeping lightweight pointers in the repository. The exam presents it as the solution when a repository has grown unmanageably large due to committed binaries — migrating existing large files to LFS with git lfs migrate import and enforcing LFS for file extensions going forward via a .gitattributes policy.

Domain 3 — Design and Implement Build and Release Pipelines (~40–45%)

The highest-weighted domain. AZ-400 is primarily a pipeline architecture exam — understanding YAML pipeline structure, multi-stage delivery, deployment strategies, and release governance is what the exam tests most deeply.

  • Azure Pipelines YAML structure: trigger (CI trigger on branch/path patterns), pool (Microsoft-hosted agents vs self-hosted agent pools), variables (pipeline variables, variable groups linked to Azure Key Vault, runtime parameters), stages → jobs → steps hierarchy. The exam tests when to use dependsOn and condition to build non-linear pipeline graphs — for example, deploying to production only if both the build stage and the automated acceptance test stage succeeded, and running the rollback job only if the deployment stage failed.
  • YAML templates: the mechanism for reusable pipeline code across multiple pipelines. A steps template (shared step sequence), a jobs template (shared job definition with parameters), and a stages template (shared stage sequence) each serve different reuse granularities. Template references across repositories (@repoAlias syntax) allow a platform team to own canonical pipeline templates that application teams consume without copying. The exam presents template composition as the answer when a scenario describes 20 application pipelines all implementing the same security scanning steps slightly differently — centralise into a template, enforce adoption via pipeline decorator or branch policy.
  • GitHub Actions integration: Azure service principal authentication from GitHub Actions via federated identity credentials (OIDC — no stored client secrets), azure/login action, and deployment to Azure App Service, AKS, or Azure Functions from GitHub workflows. The exam tests OIDC federation as the preferred authentication pattern (vs storing a long-lived client secret as a GitHub repository secret) because it eliminates the need to rotate credentials and produces time-bounded tokens scoped to a specific workflow run.
  • Self-hosted agent pools: when Microsoft-hosted agents are insufficient — private network access requirements, custom toolchain, longer build times, compliance requirements for build environment control — self-hosted agents on Azure VMs or Azure Container Instances provide the execution environment. Azure Virtual Machine Scale Set agents provide auto-scaling self-hosted capacity: the pool scales to zero when idle and scales up on demand, combining cost efficiency with private network access. The exam tests VMSS agent pools as the answer for scenarios that require both private network access (accessing an on-premises artefact repository) and elastic capacity (variable build concurrency throughout the day).
  • Deployment strategies: Rolling (update a fraction of instances at a time; App Service deployment slots + traffic routing percentage; suitable when the application tolerates mixed-version traffic). Blue/green (two identical environments; Azure Traffic Manager or Application Gateway routes all traffic to one; swap is atomic; zero-downtime with instant rollback by re-routing traffic back to blue). Canary (weighted traffic split to route a small percentage of production traffic to the new version; Application Gateway weighted backend pools or Azure Front Door origin weights; monitors Application Insights alerts before incrementing the split). The exam maps stated requirements (zero downtime, rollback time budget, cost tolerance during deployment) to the correct strategy.
  • Environments and approvals: Azure Pipelines Environments represent deployment targets (Kubernetes namespaces, virtual machines, or abstract approval gates). Approval checks require a designated approver to review and approve before the pipeline proceeds to a stage targeting that environment. Exclusive lock ensures only one deployment runs against an environment at a time — preventing a pipeline queued behind a canary release from skipping ahead. The exam tests multi-approval workflows for regulated environments where both a security approver and a change manager must approve before production deployment proceeds.
  • Artefact management: Azure Artifacts hosts private npm, NuGet, PyPI, Maven, and Cargo feeds. Upstream sources proxy and cache packages from public registries (npmjs.com, nuget.org) through the private feed — builds never reach the public internet directly, enabling air-gapped environments and supply-chain audit trails. Package versioning and retention policies (delete packages below a download threshold after N days) keep feeds from accumulating unbounded build artefacts. The exam tests Artifacts + upstream sources as the answer for regulated build environments that must control which public packages can enter the build.
Exam pattern: multi-stage YAML

A question presents a pipeline that builds and deploys an application but production deployments bypass approval. The answer is to add an Azure Pipelines Environment with an approval check targeting the production stage, not to modify the YAML condition expression — approval checks live on the Environment resource, not inside the pipeline YAML. The YAML pipeline targets the environment by name; the approval configuration is set on the Environment in the Azure DevOps portal.

Domain 4 — Develop a Security and Compliance Plan (~10–15%)

DevSecOps — security integrated into the development and delivery pipeline rather than appended at the end — is the conceptual framework this domain tests. The exam approaches security not as a gate before production but as a continuous check at every stage of the pipeline.

  • Microsoft Defender for DevOps: the Azure-native DevSecOps surface that aggregates security findings from Azure Pipelines and GitHub into Microsoft Defender for Cloud. It surfaces secret scanning results, Infrastructure as Code (IaC) misconfigurations (ARM templates, Bicep, Terraform files scanned for insecure defaults), and open-source dependency vulnerability findings in a single pane alongside cloud workload findings. The exam tests Defender for DevOps as the mechanism for providing a CISO-level view of pipeline security posture without requiring the security team to access individual pipeline runs or repository scans directly.
  • Dependency scanning and SCA: Software Composition Analysis (SCA) tools (OWASP Dependency Check, Snyk, GitHub Dependabot, or the Azure DevOps Dependency Check task) scan third-party package manifests (package.json, requirements.txt, pom.xml) against vulnerability databases (NVD, GitHub Advisory Database) and fail the build when packages with CVEs above a configured CVSS threshold are detected. The exam distinguishes SCA (scanning what you import) from SAST (scanning what you write).
  • Static Application Security Testing (SAST): tools like GitHub Advanced Security code scanning (CodeQL), SonarQube, or Checkmarx analyse source code for security vulnerabilities (SQL injection patterns, hardcoded credentials, unsafe deserialisation) without executing the application. Results are surfaced as pull request annotations — blocking merge on high-severity findings before code reaches the main branch. The exam tests SAST in the PR validation step (blocking merge) rather than as a post-deployment scan, because fixing a vulnerability before it merges is cheaper than fixing it after it ships.
  • Container image scanning: integrating Trivy, Aqua, or Microsoft Defender for Containers into the build pipeline to scan container images for OS-level CVEs and misconfigurations before pushing to Azure Container Registry. ACR Tasks can trigger automatic rescanning of images already in the registry when new CVE data is published — the exam tests this “continuous registry scanning” pattern as the answer for keeping a registry free of newly-discovered vulnerabilities in images that were clean when first pushed.
  • Infrastructure as Code security scanning: Azure Policy and Checkov (or the Azure DevOps Security IaC task) scan ARM/Bicep/Terraform templates before deployment for common misconfigurations: storage accounts with public access enabled, NSG rules allowing port 22/3389 inbound from any source, Key Vaults without soft-delete, managed disks without encryption. The exam maps IaC scanning to the pipeline stage where templates are validated but before az deployment or terraform apply runs — catching misconfigurations before they create real resources.
  • Azure Key Vault integration: referencing secrets from Azure Key Vault in Azure Pipelines via a linked variable group (the pipeline retrieves the secret at run time using the pipeline service principal’s identity — the secret value is never stored in pipeline configuration). Managed Identity for pipeline agents eliminates the service principal client secret entirely. The exam tests this pattern as the answer for any scenario where a secret is currently stored as a pipeline variable in plaintext or as a GitHub repository secret.
  • Compliance and audit: Azure DevOps audit logs (all pipeline runs, environment approvals, and permission changes are logged to a tamper-resistant audit stream that can be exported to Azure Monitor Logs or a SIEM). Policy as Code enforces compliance continuously — Azure Policy deny effects prevent non-compliant resource creation even if a pipeline deploys an incorrect template. The exam tests audit log export as the answer when a compliance team needs to demonstrate to an auditor that all production changes went through an approved change process.

Domain 5 — Implement an Instrumentation Strategy (~10–15%)

Shipping code is not the end of the DevOps loop — observing its behaviour in production and feeding that signal back into the development cycle closes it. This domain tests the Azure observability stack:

  • Application Insights: the application performance monitoring (APM) tier of Azure Monitor. Auto-instrumentation for .NET, Java, Node.js, and Python on App Service and AKS adds request tracing, dependency tracking, and exception collection with minimal code change. Custom telemetry events (trackEvent), metrics (trackMetric), and dependencies (trackDependency) extend built-in instrumentation for business-level observability. Live Metrics provides a near-real-time view of incoming request rate, failure rate, and dependency call latency — the first screen to open during an active production incident. Application Map renders the call graph between microservices with dependency health overlaid — the exam answer when a scenario asks how to identify which upstream service is responsible for a latency spike in a distributed application.
  • Log Analytics Workspace: the centralised log ingestion and query platform. All Azure resource diagnostic logs, Application Insights telemetry, Container Insights logs, and custom application logs can be routed to a single workspace. KQL (Kusto Query Language) queries across tables — requests, exceptions, customEvents, traces, dependencies — enable cross-signal correlation that is not possible when logs and metrics live in separate systems. Workspace-based Application Insights (vs classic) is the current-generation pattern: the exam tests creating Application Insights resources linked to a shared workspace rather than the legacy isolated storage model.
  • Azure Monitor alerts: Metric alerts fire on a threshold crossing (CPU > 85% for 5 minutes; response time p95 > 2 seconds). Log alert rules evaluate a scheduled KQL query and fire when the result exceeds a row count or metric threshold (e.g. more than 10 exceptions per minute from a specific operation). Smart detection (Application Insights anomaly detection) fires when failure rate or response time deviates from the baseline for that time of day — reducing false positives from time-of-day variation without requiring manual threshold tuning. The exam presents smart detection as the answer when a scenario describes alert fatigue from metric threshold alerts that fire every Monday morning during peak load even when there is no real incident.
  • Feature flags: Azure App Configuration feature management decouples feature deployment from feature release. A feature is deployed to production in a disabled state; enabling it for a percentage of users (or a specific user segment) is a configuration change, not a deployment. This enables dark launches (feature is deployed and telemetry is collected but users cannot see it yet), progressive rollout (enable for 5% of users, observe metrics, increment to 100% if healthy), and instant kill switch (disable a misbehaving feature without rolling back the deployment). The exam tests feature flags as the answer when a scenario asks how to safely validate a high-risk change in production without a canary deployment strategy — feature flags provide user-segment granularity that traffic-splitting strategies do not.
  • DORA metrics and deployment frequency: the four DORA (DevOps Research and Assessment) metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recover — are the industry-standard measures of DevOps performance. Azure DevOps includes a built-in DORA metrics report at the organisation level. The exam tests DORA metrics as the answer when a scenario asks how to benchmark the team’s DevOps maturity and identify which metric to target to move from “Medium” to “High” performer. A team with high Deployment Frequency but high Change Failure Rate is deploying often but breaking things often — the bottleneck is test coverage and pipeline quality gates, not deployment cadence.
Exam pattern: feature flags vs canary

A scenario describes a team that wants to test a new checkout flow in production against 1% of real users, with the ability to disable it instantly if error rates rise, without any additional infrastructure. The answer is Azure App Configuration feature flags with a percentage filter — not a canary deployment to a separate App Service slot, which requires additional infrastructure and cannot target individual users. Feature flags and canary deployments are both valid strategies but solve different problems; the exam tests knowing which fits the stated constraint.

The AZ-400 concept that most surprises candidates who primarily use the Azure portal: the exam is almost entirely YAML-first. Classic release pipelines (the GUI-based “drop zones” model with deployment groups and task lists) are not the exam pattern — multi-stage YAML with environments, approval checks, and template composition is. Candidates who have only used the classic pipeline editor will find the YAML pipeline domain unfamiliar even if they have significant Azure DevOps production experience. Spend time writing real multi-stage YAML pipelines, including templates, before sitting the exam.

AZ-400 vs DOP-C02 vs Professional Cloud DevOps Engineer

All three expert DevOps certifications test CI/CD pipeline architecture, deployment strategies, and production observability. The differences reflect each cloud provider’s toolchain and philosophy:

AWS DOP-C02 emphasises AWS-native pipeline services (CodePipeline, CodeBuild, CodeDeploy) and IaC automation via CloudFormation and CDK. The Deployment Pipeline Architecture domain (22% weight) is highest, but the Security and Compliance domain (17%) and Configuration Management domain (17%) are nearly equal. DOP-C02 is more IaC-heavy than AZ-400.

GCP Professional Cloud DevOps Engineer is the most SRE-theoretically grounded of the three, with an explicit domain on SLO/SLI error-budget management drawn directly from Google’s SRE Book. Domain 3 (Applying SRE Practices) carries 25% weight — there is no equivalent domain in AZ-400 or DOP-C02. The GCP cert is the right signal for candidates whose role involves SRE practices explicitly; AZ-400 and DOP-C02 assume DevOps in the broader CI/CD and automation sense.

AZ-400 is the most DevSecOps-prominent of the three — Defender for DevOps, IaC security scanning, and SCA/SAST integration each have dedicated exam weight. The GitHub Actions integration domain reflects Microsoft’s acquisition of GitHub and the real-world pattern where many teams running on Azure deploy via GitHub Actions rather than Azure Pipelines natively. For engineers operating in Microsoft-centric enterprises (Azure + GitHub + M365), AZ-400 is the highest-signal DevOps credential available.

Study recommendations for AZ-400

AZ-400 has more hands-on prerequisite depth than most Azure certs. Before sitting the exam: (1) Build a real multi-stage YAML pipeline with a build stage, a staging deployment stage, and a production deployment stage using Environments and approval checks. (2) Create a YAML template in a separate repository and reference it from your main pipeline. (3) Configure a GitHub Actions workflow that authenticates to Azure via OIDC federation (no client secrets). (4) Wire Application Insights to an application and write a KQL query in Log Analytics that correlates request failures with exception stack traces. These four hands-on exercises cover the four highest-weight concept clusters on the exam — doing them once is worth more than re-reading the study guides five times.

Sharpen your Azure DevOps, Pipelines, and cloud delivery knowledge with targeted practice on CertQuests.

Browse Azure Practice Tests →