- Published: 2026-02-03
- Last updated: 2026-02-03
- Exam reference: AZ-400, Designing and Implementing Microsoft DevOps Solutions
AZ-400 is Microsoft’s DevOps exam, with its closest real-world match in source control, pipeline automation, release governance, security integration, and infrastructure as code. The gap appears when exam scenarios become production systems, where cost control, deployment drift, rollback design, observability, agent management, and audit evidence matter as much as a working pipeline.
The official AZ-400 exam page on Microsoft Learn should be treated as the source of truth for skills measured, registration details, and changes to the exam outline. Microsoft updates certification pages periodically, so candidates should check the official outline close to the exam date rather than relying on older blog posts, screenshots, or study notes.
What AZ-400 Really Measures
AZ-400 is designed for practitioners who can design and implement DevOps processes on Azure. It assumes familiarity with development practices, cloud operations, source control, automated testing, infrastructure as code, release strategies, and security controls across the software delivery lifecycle.
In practical terms, the exam rewards candidates who understand how work flows from a backlog item into a pull request, through automated validation, into a deployable artifact, and finally into controlled environments. It is less about memorising every button in the portal and more about knowing which control belongs where: branch policy in the repository, validation in the pipeline, approvals at the environment boundary, and operational signals after release.
The related Microsoft certification path is the Azure DevOps Engineer Expert credential. Candidates often arrive from either an administrator or developer background, and both routes can work. Administrators usually need deeper practice with Git, YAML, and test automation, while developers often need more exposure to identity, networking, deployment governance, and production operations.
Azure DevOps in the Context of the Exam
Azure DevOps is a suite of services for planning work, hosting repositories, building and releasing software, testing applications, and managing packages. For AZ-400, the most important services are usually Azure Repos, Azure Pipelines, Azure Artifacts, and the governance features that connect them to controlled deployment environments.
Azure Boards and dashboards matter because DevOps is not only a pipeline problem. Teams need traceability from work item to commit, build, release, and incident. That traceability is useful in the exam, but it is also one of the reasons many enterprises continue to use Azure DevOps for regulated delivery: audit trails and cross-project visibility are easier to standardise when the planning, repository, pipeline, and release records live in a consistent workflow.
GitHub also appears in modern DevOps study paths, especially for source control, pull requests, Actions-based automation, and security workflows. A useful decision point is governance. GitHub is often attractive where engineering teams want a developer-centred workflow, open-source alignment, and strong repository-level collaboration. Azure DevOps is often chosen where organisations need mature approval flows, multi-project reporting, and established release controls across Azure-heavy estates. AZ-400 candidates should be comfortable with both concepts, even if their own workplace has standardised on one platform.
Where the Exam Mirrors Real Work
The strongest overlap between AZ-400 and daily work is in pipeline design. A reliable delivery process builds the same way every time, runs tests before deployment, publishes a versioned artifact, applies infrastructure consistently, and promotes the release through controlled environments. This is exactly the kind of thinking AZ-400 expects.
Branch governance is another area where the exam maps well to practice. A team that allows direct commits to the main branch, skips pull request validation, or treats code review as optional will eventually see unstable builds and unclear ownership. In Azure Repos, branch policies can require a minimum number of reviewers, successful build validation, linked work items, comment resolution, and restrictions on who can bypass policy. Those controls are not bureaucracy when they are tuned correctly; they protect the shared integration branch from avoidable defects.
Release strategy is where candidates need to move beyond definitions. Trunk-based development can work well when teams invest in feature flags, small pull requests, automated testing, and fast rollback. Release branches may suit products with longer support windows or strict release trains, but they create merge overhead and require discipline to avoid divergence. Canary and blue-green patterns reduce release risk, yet they also require monitoring, routing control, rollback criteria, and a clear owner for the decision to continue or stop a deployment.
A Practical Multi-Stage Pipeline Pattern
A useful AZ-400 practice scenario is a small web application deployed to Azure with infrastructure defined as code. The pipeline should build the application, run tests, perform a tool-agnostic security scan step, publish an artifact, validate infrastructure, and deploy only after an environment approval. This mirrors a common enterprise pattern without depending on a specific third-party scanner or proprietary deployment convention.
The architecture can be described as a repository feeding a CI stage, which produces a versioned artifact and an infrastructure plan. The release stage then targets a named Azure DevOps environment, where approvals and checks control promotion to test or production. In a real implementation, that environment boundary is where change control, operational ownership, and audit evidence become visible.
The following example is intentionally compact. It is suitable for learning pipeline structure, not for copying into production without adapting service connections, environment names, test commands, artifact retention, and deployment permissions.
Example — multi-stage Azure Pipelines YAML with validation and a gated deployment
trigger:
branches:
include:
- main
pr:
branches:
include:
- main
variables:
buildConfiguration: Release
azureServiceConnection: sc-az400-demo
resourceGroupName: rg-az400-demo-test
location: westeurope
stages:
- stage: Build_Test_Scan
displayName: Build, test, and scan
jobs:
- job: ValidateApplication
pool:
vmImage: ubuntu-latest
steps:
- checkout: self
- task: DotNetCoreCLI@2
displayName: Restore dependencies
inputs:
command: restore
projects: src/WebApp/WebApp.csproj
- task: DotNetCoreCLI@2
displayName: Build application
inputs:
command: build
projects: src/WebApp/WebApp.csproj
arguments: --configuration $(buildConfiguration) --no-restore
- task: DotNetCoreCLI@2
displayName: Run tests
inputs:
command: test
projects: tests/WebApp.Tests/WebApp.Tests.csproj
arguments: --configuration $(buildConfiguration) --no-build
- script: |
echo "Run dependency, secret, and code scanning here"
echo "Fail the job when policy thresholds are exceeded"
displayName: Security policy validation
- publish: $(Build.SourcesDirectory)/infra
artifact: infra
- stage: Plan_Infrastructure
displayName: Validate infrastructure
dependsOn: Build_Test_Scan
jobs:
- job: WhatIf
pool:
vmImage: ubuntu-latest
steps:
- download: current
artifact: infra
- task: AzureCLI@2
displayName: Preview Bicep changes
inputs:
azureSubscription: $(azureServiceConnection)
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
az deployment group what-if \
--resource-group $(resourceGroupName) \
--template-file $(Pipeline.Workspace)/infra/main.bicep \
--parameters location=$(location)
- stage: Deploy_Test
displayName: Deploy to test
dependsOn: Plan_Infrastructure
jobs:
- deployment: DeployWebApp
environment: az400-test
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: infra
- task: AzureCLI@2
displayName: Apply infrastructure
inputs:
azureSubscription: $(azureServiceConnection)
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
az deployment group create \
--resource-group $(resourceGroupName) \
--template-file $(Pipeline.Workspace)/infra/main.bicep \
--parameters location=$(location)
This pipeline demonstrates the structure candidates should understand for AZ-400: pull requests and main-branch commits trigger validation, application quality gates run before infrastructure changes, the infrastructure preview separates planning from applying, and deployment is attached to a named environment. The approval itself is configured on the Azure DevOps environment rather than embedded as a secret or manual pause inside the YAML file.
In practice, production teams would add more controls. Common additions include pipeline templates, reusable variable groups backed by Key Vault, build caching, test parallelisation, signed artifacts, deployment rings, environment-specific approvals, and observability hooks that confirm whether the release is healthy after deployment. These are often the details that distinguish a functioning demo pipeline from an operationally reliable delivery system.
Security, Compliance, and Governance in the Pipeline
AZ-400 treats security as part of the delivery system rather than a separate phase at the end. Candidates should understand how secrets are protected, how identities are scoped, how repository changes are reviewed, and how approvals are recorded. The practical goal is to make the secure path the normal path for delivery.
Secrets should not be stored directly in YAML files, plain pipeline variables, scripts, or repository history. Azure Key Vault integration, scoped service connections, managed identities where appropriate, and restricted variable groups help reduce exposure. Teams should also review who can edit pipelines, approve environments, create service connections, and bypass branch policies, because these permissions can become indirect production access.
Compliance work also depends on evidence. Pull request reviews, successful build validations, artifact versions, environment approvals, deployment logs, and work item links create a record of what changed and who approved it. Artifact signing and retention policies strengthen that record, especially when teams need to prove that a deployed package came from a controlled build rather than from a local workstation.
Common Mistakes That Undermine AZ-400 Preparation
Many weak study plans focus on recognising product names instead of building working delivery flows. Knowing that Azure Repos supports pull requests is not the same as configuring a branch policy that blocks untested changes. Knowing that Azure Pipelines supports YAML is not the same as understanding how stages, jobs, artifacts, environments, variables, and approvals interact.
A frequent mistake is staying with classic release pipelines because they feel easier at first. Classic pipelines still appear in existing organisations, so candidates may encounter them, but YAML is central to modern pipeline-as-code practice because it can be reviewed, versioned, templated, and evolved alongside the application. Another common issue is secrets sprawl: teams place sensitive values in variables, scripts, local files, or copied task inputs, then struggle to identify who used them and where they leaked.
Missing environment checks is equally damaging. A pipeline that deploys successfully but has no approval boundary, no rollback plan, no deployment history, and no health signal is incomplete. AZ-400 preparation should therefore include at least one hands-on scenario where a candidate configures repository policy, runs a multi-stage YAML pipeline, links deployment to an environment, and verifies that approval and audit records are captured.
Exam Readiness Without Losing the Practical Thread
The exam preparation process should start with the Microsoft skills outline, then move quickly into hands-on practice. Candidates should build a small repository, protect the main branch, create pull request validation, write a multi-stage YAML pipeline, publish an artifact, deploy infrastructure with Bicep or Terraform, and add environment approvals. Reading alone rarely exposes the sequencing problems that appear when these pieces are connected.
Structured training can help when candidates already work with Azure but have uneven exposure across the AZ-400 objectives. The Readynez Microsoft Certified DevOps Engineer course is one option for learners who want guided practice around the official skills areas, while the learning platform can support review and progress tracking. These resources are most useful when paired with a working lab, because the exam expects applied judgement rather than isolated terminology.
Practice exams can be helpful, but they should be used diagnostically. A low score should point to a missing skill area, such as release strategy, source control governance, package management, or secure pipeline configuration. Repeating questions without rebuilding the weak area can create familiarity with wording while leaving the underlying skill unchanged.
Beyond the Exam: What Teams Still Need to Build
AZ-400 is a strong foundation, but production DevOps maturity extends further. Teams need reusable pipeline templates, platform standards, policy as code, cost awareness, drift detection, disaster recovery testing, and observability that connects deployments to service health. These topics become more important when several teams share cloud platforms and delivery standards.
Self-hosted agents are a good example of a topic that can be underestimated. They may be required for private network access, specialised tooling, or compliance reasons, but they introduce patching, scaling, identity, and isolation responsibilities. Artifact retention is another practical issue. Keeping too little breaks traceability; keeping everything forever creates storage and governance problems. Neither decision is difficult conceptually, but both need ownership.
Candidates planning a broader Microsoft certification route may later consider paths such as Azure Solutions Architect Expert, especially if their work expands into landing zones, network design, identity architecture, and platform governance. The wider Microsoft Credentials catalogue is useful for checking current role-based options and retirement status before committing to a study path.
FAQ
What is the AZ-400 exam about?
AZ-400 focuses on designing and implementing DevOps solutions on Azure. It covers areas such as source control, CI/CD, security and compliance integration, infrastructure as code, release strategy, package management, and collaboration across the software delivery lifecycle.
Is Azure DevOps or GitHub better for AZ-400 preparation?
Candidates should understand both at a conceptual level. Azure DevOps is especially relevant for Azure Pipelines, Azure Repos, environments, approvals, and enterprise reporting. GitHub is also important for repository-centred workflows, pull requests, automation, and modern DevSecOps practices. The right workplace choice depends on governance needs, engineering workflow, reporting, and existing platform standards.
How long does it take to prepare for AZ-400?
Preparation time depends on prior experience. Someone already building Azure pipelines may need mainly exam-objective review and targeted practice, while someone new to Git, YAML, release governance, or infrastructure as code will need more lab time. The safest approach is to measure readiness against the official Microsoft skills outline and a working end-to-end pipeline scenario.
What hands-on practice is most useful for AZ-400?
The most useful practice is building a small delivery flow from repository to deployment. Candidates should configure branch policies, create pull request validation, write a multi-stage YAML pipeline, publish artifacts, deploy infrastructure as code, add environment approvals, and confirm that logs and audit records show what happened.
Does AZ-400 require production DevOps experience?
Production experience is helpful but not the only route to readiness. A candidate can prepare effectively with realistic labs, but those labs should include governance and failure scenarios rather than only successful deployments. Rollback planning, permissions, secret handling, and approval checks are important because they reflect how DevOps is implemented in real environments.
Building AZ-400 Skills That Hold Up in Production
The key takeaway is that AZ-400 preparation works best when it is tied to a real delivery model. A candidate who can explain branch policy, write YAML, secure secrets, validate infrastructure, configure approvals, and reason about release risk is preparing for both the exam and the work behind it.
Readynez can support that path with structured AZ-400 preparation, but the strongest results come when study is paired with a working repository, a controlled pipeline, and deliberate practice around the failure points that real teams face.
