AZ-400 remains Microsoft’s current Designing and Implementing Microsoft DevOps Solutions exam, with the English version updated on July 27, 2026. The AZ-400 exam requires a passing score of 700 and is the required exam for Microsoft Certified: DevOps Engineer Expert, together with the appropriate prerequisite certification path.
The current blueprint is heavily weighted toward delivery automation: Design and implement processes and communications 10–15%, Design and implement a source control strategy 10–15%, Design and implement build and release pipelines 50–55%, Develop a security and compliance plan 10–15%, and Implement an instrumentation strategy 5–10%.
Processes and communications is 10–15%
This domain covers flow of work, GitHub Flow, feedback cycles, GitHub Issues, Azure Boards/GitHub integration, traceability, DevOps metrics, dashboards, project/development/testing/security/delivery/operations queries, and collaboration/documentation.
A work-tracking model should connect backlog/work items with source, builds, releases, bugs, and quality evidence rather than exist as an isolated project-management tool.
Source control strategy is another 10–15%
The blueprint includes trunk-based, feature-branch, and release-branch strategies; pull requests; branch policies/protection; merge restrictions; Git LFS/git-fat; repository scaling/Scalar; permissions; tags; recovery; and removal of sensitive or unwanted data.
The DevOps engineer should balance collaboration, review, release needs, repository scale, and security rather than choose one branching pattern for every team.
Build and release pipelines dominate at 50–55%
More than half the blueprint covers package management, testing, pipelines, deployments, infrastructure as code, and pipeline maintenance. This weighting reflects the role’s core responsibility: continuous delivery of value through reliable automation.
A pipeline should be treated as a production system with dependencies, credentials, agents/runners, observability, cost, and failure modes—not merely a YAML file.
Package and dependency strategy is part of delivery
Current objectives include GitHub Packages, Azure Artifacts, local/upstream feeds, semantic or calendar versioning, and pipeline artifact versioning. Dependency governance affects reproducibility and supply-chain risk.
The pipeline should know exactly which artifact/version it is building and deploying rather than silently consuming “latest.”
Testing and gates are first-class objectives
Local/unit/integration/load testing, test agents/tasks, test results, code coverage, security/governance gates, and release checks all appear in the current guide. Tests should be placed where they provide useful feedback without making the pipeline unreasonably slow.
The exam can test whether a quality or security control belongs before merge, during CI, before deployment, or after release.
Pipeline design spans GitHub Actions and Azure Pipelines
Current objectives explicitly include choosing GitHub Actions versus Azure Pipelines, runner/agent infrastructure, GitHub-Azure Pipelines integration, triggers, YAML, job ordering/parallelism, hybrid/self-hosted agents, reusable templates, variables, environments, approvals, and checks.
A Azure DevOps foundation is helpful, but the exam expects candidates to work across both Azure DevOps and GitHub ecosystems.
Deployment strategies are modern and progressive
Blue-green, canary, ring, progressive exposure, feature flags, A/B testing, rolling deployment, deployment slots, hotfix paths, database tasks, and resilience all appear in the current blueprint.
The best deployment strategy balances blast radius, rollback, observability, data compatibility, user impact, and speed.
Infrastructure as code is inside the main pipeline domain
Current objectives cover configuration management strategy, source-controlled IaC, automated testing/deployment, Azure Resource Manager, Bicep, Azure Machine Configuration, Azure Automation State Configuration, and Azure Deployment Environments.
IaC should move infrastructure changes through the same review and validation discipline as application code.
Security and compliance is 10–15%
The blueprint includes service principals versus managed identities, GitHub Apps/GITHUB_TOKEN/PATs, Azure DevOps service connections, roles/permissions, Key Vault, secretless authentication through workload identity federation/OIDC, secure files, and scanning for dependencies, code, secrets, licenses, containers, and vulnerabilities.
A DevSecOps approach is explicit: security controls should be automated into the delivery system rather than added after deployment.
Instrumentation closes the feedback loop at 5–10%
Azure Monitor, Logs, Application Insights, VM/Container/Storage/Network insights, GitHub insights, pipeline alerts, infrastructure metrics, application performance, distributed tracing, and KQL all appear in the current guide.
The July 27, 2026 update makes it important to study current GitHub and Azure DevOps integration rather than rely on older Azure DevOps-only materials. Microsoft explicitly expects experience with both ecosystems, and several objectives name GitHub Flow, GitHub Issues, GitHub Projects, GitHub Actions, GitHub Apps, GitHub Advanced Security, and integration with Azure Boards or Azure Pipelines.
Flow-of-work design should be treated as part of delivery architecture. Work items, issues, repositories, commits, pull requests, builds, releases, bugs, and incidents should be traceable enough that teams can answer why a change exists and what outcome it produced. Poor traceability makes auditing and incident response harder.
Current DevOps metrics include cycle time, lead time, time to recovery, and stage-specific planning, development, testing, security, delivery, and operations metrics. A dashboard should support decisions rather than maximize the number of charts. Metrics can create bad incentives when teams optimize the number instead of the delivery outcome.
Documentation objectives include wikis, Markdown, Mermaid diagrams, release notes, API documentation, and automated documentation from Git history. Documentation belongs in the delivery system because it should evolve with the code and release rather than become an afterthought after production changes.
Webhooks and integrations connect DevOps tools to collaboration or automation. A webhook can trigger a downstream system when repository, pipeline, or work-item events occur. The design question is which event should cause action and how authentication, retries, and duplicate events are handled safely.
Repository-scaling objectives include Git LFS, git-fat, Scalar, tags, permissions, and cross-repository sharing. Large monorepos or binary-heavy repositories can slow clones and builds; the exam expects candidates to know when repository architecture itself becomes a delivery bottleneck.
Removing sensitive data from source control is an important current objective. Deleting a file in the latest commit may not remove it from Git history. Teams need an incident response for exposed secrets: revoke/rotate the secret, remove or rewrite history where appropriate, and prevent recurrence with scanning.
Package feeds and upstream sources should be governed because dependencies can introduce supply-chain risk. Views or promotion patterns can separate unvalidated packages from approved versions, while semantic or calendar versioning communicates change. Artifact provenance becomes part of release confidence.
Quality gates should combine technical evidence with governance requirements. Unit tests, integration tests, load tests, security scans, license checks, code coverage, and approvals can all gate promotion, but placing every expensive check on every commit can damage feedback speed. Pipeline design balances confidence with flow.
Agent and runner infrastructure is explicitly an architecture topic. Hosted agents reduce maintenance, while self-hosted runners can provide private connectivity or specialized tooling but create patching, isolation, credential, scaling, and cost responsibilities. The exam can ask for the model that fits the workload.
Reusable YAML templates and task groups reduce duplication, but they create shared dependencies. A bad template can break many pipelines at once. Versioning, review, testing, and backward compatibility therefore matter for pipeline building blocks just as they do for application libraries.
Approvals and checks around environments separate successful build from authorized deployment. An artifact can pass CI yet still require change approval, business validation, security sign-off, or an exclusive lock before production. Modern delivery is fast because controls are automated and clear, not because controls disappear.
Progressive deployment is one of the strongest current themes. Canary, ring, blue-green, feature flags, and A/B patterns let teams expose changes gradually, observe behavior, and reduce blast radius. The deployment design should define what evidence causes promotion, pause, or rollback.
Hotfix-path planning belongs in the blueprint because urgent fixes need speed without abandoning traceability or security. A hotfix path should be shorter, not uncontrolled: minimal change, focused testing, clear approval, versioning, and post-release reconciliation with the main branch are still important.
Database deployment is a special case because schema and data changes can be difficult to roll back. Pipelines should order dependencies, maintain backward compatibility where possible, and avoid application versions that depend on a schema state not yet deployed. Release design needs data awareness.
Azure Deployment Environments reflects self-service platform engineering. Teams can provision approved environments from controlled definitions on demand, reducing ticket queues while preserving governance. The exam’s IaC section therefore includes developer experience as well as configuration syntax.
Pipeline maintenance includes health, failure rate, duration, flaky tests, concurrency, cost, performance, reliability, artifact retention, and classic-to-YAML migration. A pipeline can become technical debt just like an application if it is never refactored or monitored.
Workload identity federation and OIDC are important because they reduce long-lived secrets between GitHub/Azure Pipelines and cloud resources. Short-lived tokens based on trusted workload identity are generally easier to rotate and less damaging if a static secret would otherwise be exposed.
GitHub Advanced Security and Defender for Cloud DevOps Security connect code/repository findings with cloud-security posture. Code, secret, dependency, license, and container scanning create evidence before deployment, while runtime posture and monitoring show what happens afterward. DevSecOps spans both stages.
Instrumentation is only 5–10%, but it influences deployment confidence everywhere. Application Insights distributed tracing, infrastructure metrics, pipeline alerts, and KQL can show whether a release improved or degraded user experience. Without telemetry, progressive delivery becomes guesswork.
The current certification page also emphasizes that DevOps engineers work across developers, SREs, Azure administrators, and security engineers. That cross-functional role explains why AZ-400 includes collaboration, security, infrastructure, application delivery, and observability in one exam rather than treating them as separate specialties.
For final scope control, remember that the five percentages describe emphasis, not isolated silos. A single pipeline scenario can test source control, security, release strategy, and instrumentation together. The best preparation connects those domains around one delivery system instead of studying them as five independent chapters.
A continuous-monitoring model helps explain why DevOps is a loop: plan → code → build → deploy → observe → learn → improve.