Microsoft AZ-400: Skills and Scope

The AZ-400 exam validates the Microsoft DevOps Engineer Expert role. Microsoft’s current English blueprint, updated July 27, 2026, measures five areas: processes and communications, source control, build and release pipelines, security and compliance, and instrumentation.

The exam is not only about Azure Pipelines. Microsoft expects candidates to work across GitHub and Azure DevOps and to connect people, process, source control, automation, testing, security, deployment, monitoring, and feedback into a continuous delivery system.

Processes and communications shape the delivery system

The first domain is smaller in weight but fundamental in practice. DevOps work begins with flow of work, collaboration, traceability, feedback, and the way teams coordinate around delivery.

Candidates should understand how boards, work items, repositories, pull requests, pipelines, environments, dashboards, and communication channels create one observable delivery process.

A technically excellent pipeline can still fail the organization if work is invisible, feedback is slow, or ownership is unclear.

Scenario questions often reward the design that shortens feedback loops without sacrificing traceability or governance.

Flow metrics can expose hidden delivery problems. Lead time, cycle time, work in progress, deployment frequency, failed change rate, and recovery time are useful when they support improvement rather than become targets teams game. AZ-400 candidates should know how process visibility and feedback influence technical delivery, because DevOps is as much about reducing friction between people and systems as it is about running automation.

Source control is about strategy, not basic Git commands

AZ-400 expects candidates to design repository structures, branching approaches, permissions, policies, pull-request workflows, code ownership, and change traceability.

The right strategy depends on team size, release cadence, product boundaries, and compliance rather than one universal branching model.

Branch policies, protected branches, reviews, and automated validation should keep risky changes out of important branches while preserving developer flow.

The exam is less concerned with memorizing Git syntax than with creating a source-control system teams can operate safely at scale.

Repository structure should reflect product boundaries and ownership. A monorepo can simplify coordinated change and make permissions or build scope more complex; multiple repositories can isolate teams and create integration overhead. The exam may present both as viable, so the stronger answer follows the stated team structure, dependency pattern, and release model rather than a universal preference.

Build and release pipelines dominate the blueprint

Microsoft assigns 50–55% of the current exam to build and release pipelines, making this the clear center of AZ-400.

Candidates need practical CI/CD knowledge: pipeline structure, agents or runners, artifacts, environments, approvals, deployment strategies, templates, testing, secrets, and rollback.

The key skill is producing a repeatable path from commit to production where the same reviewed artifact can be promoted through environments.

A pipeline is strongest when failures are visible, deployments are reversible, and environment-specific configuration does not require rebuilding the application.

Deployment strategy is a recurring practical skill. Blue-green, canary, rolling, feature-flag, and ring-based approaches control risk differently. Candidates should understand how health checks, approvals, environment protection, artifact promotion, and rollback fit around the chosen strategy. A deployment method is successful only when the team can detect bad behavior early and return users to a known-good version without improvisation.

Infrastructure deployment belongs in the same release model as application deployment. Bicep, ARM, Terraform, or other IaC should be validated, reviewed, and promoted with clear environment boundaries. If infrastructure changes are made manually outside the pipeline, teams lose traceability and make rollback harder. Practice a pipeline that changes both application and infrastructure safely so the release process reflects the complete production state.

GitHub and Azure DevOps are both part of the role

The GitHub Actions exam represents deeper workflow-specific knowledge, but AZ-400 expects familiarity with both GitHub and Azure DevOps solutions.

Candidates should understand how repositories, actions or pipelines, packages, environments, secrets, approvals, and identity can be combined in either ecosystem.

The products differ in implementation details, but the DevOps principles remain the same: versioned workflow, automated validation, controlled promotion, and observable outcome.

Study the purpose of each capability first, then learn where Microsoft exposes it in GitHub or Azure DevOps.

Reusable templates matter because pipelines often repeat the same build, scan, packaging, and deployment logic across repositories. Central templates can create consistency and reduce maintenance, but versioning them badly can also create organization-wide breakage. Practice one shared pipeline template and one consumer repository so you can see how parameters, permissions, and change control affect reuse.

Security and compliance belong inside the pipeline

Security is not a gate added after development. AZ-400 includes secret management, dependency scanning, code scanning, policy, permissions, compliance checks, and secure pipeline design.

Automated checks should fail early enough to protect production without creating meaningless noise that teams learn to ignore.

Use least-privilege identities for pipelines and isolate high-impact production credentials from ordinary build activity.

A strong design can show which control ran, what it found, who approved an exception, and which artifact was eventually deployed.

Software supply-chain security should include dependencies, packages, artifacts, credentials, and the infrastructure that performs the build. Signing or provenance, protected feeds, secret scanning, and controlled runner identities reduce the chance that a trusted pipeline distributes untrusted output. Security evidence should remain attached to the release so auditors and incident responders know what checks were performed.

Instrumentation closes the DevOps feedback loop

The instrumentation domain covers monitoring strategy, metrics, logs, traces, alerts, dashboards, and feedback from production into engineering work.

The goal is not to collect every possible signal. Teams need telemetry that reveals whether a release improved reliability, performance, and user experience or introduced regression.

Deployment markers help operators correlate a change with new errors or latency.

When monitoring feeds the backlog and release process, observability becomes part of continuous improvement rather than a separate operations activity.

Service-level indicators and objectives make telemetry actionable. An alert should represent a condition that matters to users or operators, not simply a metric crossing an arbitrary number. Practice connecting an application metric to a release, creating a dashboard, and defining when the team should stop a rollout. This joins instrumentation with release governance instead of treating monitoring as a separate afterthought.

AZ-104 provides the administrator boundary

The AZ-104 exam is a useful foundation for Azure administration across identity, compute, storage, networking, and monitoring.

AZ-400 candidates are expected to have experience administering and developing in Azure, with strong skills in at least one of those areas.

If basic Azure resources, identities, networking, and monitoring are still unfamiliar, DevOps pipeline scenarios become harder because every deployment target looks new.

Use AZ-104 knowledge as platform context, not as extra AZ-400 syllabus.

Hands-on Azure administration also teaches what pipelines are changing. A deployment identity needs access to real subscriptions, resource groups, Key Vault, networks, and application platforms. When AZ-400 scenarios mention failed deployments, the root cause may be an Azure permission or resource issue rather than pipeline syntax. Platform fluency helps candidates debug the boundary instead of rebuilding the workflow unnecessarily.

AZ-305 is an architecture boundary, not a prerequisite

The AZ-305 exam focuses on Azure solution architecture rather than DevOps delivery mechanics.

Architects decide the target platform and nonfunctional requirements; DevOps engineers design the flow that builds, secures, deploys, monitors, and improves that platform.

The two roles overlap around automation, governance, reliability, and operations, but they optimize different parts of the lifecycle.

Keeping that boundary clear prevents AZ-400 study from drifting into every Azure architecture service.

Architects may define availability, security, network, and compliance requirements that the DevOps engineer must encode into delivery workflows. For example, a region-pair architecture can require separate environments, staged promotion, infrastructure validation, and failover testing. Understanding that handoff makes AZ-400 stronger without requiring candidates to study the complete AZ-305 blueprint.

Use the July 2026 Microsoft blueprint as the study spine

The DevOps Engineer Expert certification provides the credential context for AZ-400.

The existing AZ-400 preparation material can support a study plan, but Microsoft Learn should control live scope.

Final preparation should emphasize integrated labs: commit code, validate it, build one artifact, scan it, deploy it progressively, observe the result, and roll back a deliberate failure.

If that lifecycle feels coherent from developer commit through production feedback, the exam domains are working together as intended.

A final lab should include both GitHub and Azure DevOps touchpoints so the exam’s cross-platform expectations are real. Use source control policies, build an artifact, run automated tests and scans, deploy through protected environments, publish telemetry, and deliberately trigger a rollback. Document the evidence at each stage. That one lifecycle exposes gaps far more clearly than reviewing five exam domains separately.

The Microsoft exam inventory can help with internal navigation across Azure and DevOps roles.

Use the 10–15%, 10–15%, 50–55%, 10–15%, and 5–10% weighting to allocate final study time. Build-and-release depth should dominate, but do not ignore instrumentation or communications because those smaller domains often determine whether a pipeline is actually operable.

Keep one release journal that records commit, artifact, security checks, approvals, deployment version, telemetry, and rollback outcome. That traceability exercise mirrors the DevOps lifecycle Microsoft is testing.

• Category: All Certifications Certifications