How to Prepare for AZ-400 DevOps Engineer Expert

AZ-400 is not a generic “learn Azure DevOps” exam. Microsoft positions it as the professional assessment for DevOps engineers who connect people, processes, source control, build and release automation, security, monitoring, and feedback into a continuous delivery system. The current English-language skills outline was updated on July 27, 2026, and it remains heavily weighted toward build and release pipelines.

Passing AZ-400 is only one part of the Microsoft Certified: DevOps Engineer Expert path. Candidates must also hold either Azure Administrator Associate or Azure Developer Associate. That prerequisite matters because Microsoft expects DevOps engineers to understand both development and administration well enough to automate delivery responsibly.

Understand the current certification path before studying

The current Microsoft Certified: DevOps Engineer Expert credential requires AZ-400 plus one qualifying associate certification. The exam itself has no listed retirement date, but Microsoft updates objectives periodically, so older courses should always be compared with the current skills outline.

The AZ-400 exam currently measures five broad areas: processes and communications, source control, build and release pipelines, security and compliance, and instrumentation. Build and release pipelines carry roughly half of the exam weighting, which should influence how candidates divide practice time.

Choose the prerequisite that matches your background rather than treating it as paperwork. Azure Administrator Associate suits candidates whose experience is strongest in infrastructure and operations. Azure Developer Associate suits candidates coming from application development. AZ-400 assumes the DevOps engineer can work across both worlds even if one remains the deeper specialty.

That expectation should shape preparation. Infrastructure-focused candidates should deliberately practice application delivery, testing, and developer workflows. Developer-focused candidates should spend time on identities, environments, infrastructure, monitoring, and operational recovery. The exam is designed around the boundary between those disciplines.

Processes and communications are part of the technical system

DevOps is not effective when engineering tools automate a dysfunctional delivery process. Candidates need to understand work tracking, collaboration, feedback loops, team communication, flow, traceability, and how delivery metrics expose constraints.

Study these topics through real delivery questions. How does work move from idea to deployed change? Where are approvals necessary? Which signals indicate blocked flow? How are incidents and customer feedback connected back to engineering? A technically perfect pipeline still fails the organization if no one can understand what it delivered or why.

Include traceability in the model. Teams should be able to connect a requirement or work item with code, build results, release evidence, and production behavior without creating excessive manual reporting. This becomes especially important when auditors, security teams, or incident responders need to reconstruct how a change reached production.

Source control is a strategy problem, not a Git command quiz

Microsoft expects candidates to reason about repository structure, branching, pull requests, permissions, policies, recovery, and secure collaboration across GitHub and Azure Repos. The current AZ-400 source-control scope is therefore broader than memorizing common Git commands.

Practice designing a strategy for a team: decide repository boundaries, branch protections, merge rules, reviewer requirements, secret handling, and what happens when a bad change reaches the main branch. You should be able to explain why the policy exists and how it affects delivery speed and risk.

Include recovery scenarios. A repository strategy is incomplete if the team cannot handle accidental deletion, compromised credentials, a bad merge, or a need to restore a known-good state. Security and resilience belong inside source-control design rather than being treated as separate operational topics.

Repository design also affects scale. Monorepo and multirepo approaches change permissions, ownership, build triggers, dependency management, and release coordination. AZ-400 scenarios are easier when you can explain those consequences rather than treating repository layout as a style preference.

Build and release pipelines deserve most of your hands-on time

Microsoft currently weights build and release pipelines at about 50–55 percent of AZ-400. Candidates should be comfortable with continuous integration, artifacts, test stages, deployment strategies, environments, approvals, reusable templates, agents or runners, and both Azure Pipelines and GitHub Actions.

The underlying concepts are easier to retain when treated as one CI/CD delivery system. A commit triggers a controlled sequence that builds, tests, packages, promotes, deploys, validates, and produces evidence. Practice failures as well as successful runs: broken dependencies, failed tests, inaccessible secrets, deployment health failures, and rollback decisions reveal whether you understand the pipeline.

Rehearse deployment strategies rather than only pipeline syntax. Blue/green, canary, rolling, staged approvals, feature flags, and rollback mechanisms solve different risk problems. A scenario may ask which design limits user impact, preserves evidence, or supports rapid recovery rather than which YAML keyword is valid.

Artifact integrity belongs in the same decision. Teams should know exactly what was built, tested, approved, and deployed. Rebuilding a different artifact in each environment weakens traceability. Promote the same tested artifact where possible and keep environment-specific configuration explicit.

Infrastructure as code should be tested like application code

DevOps engineers increasingly define infrastructure through templates and declarative configuration. That means infrastructure needs version control, review, reusable modules, validation, state awareness, drift management, and safe deployment patterns.

Infrastructure as code becomes valuable when it makes environments reproducible and auditable rather than simply moving manual configuration into a text file. Practice changing infrastructure through pull requests, validating the planned effect, and recovering when the deployed environment no longer matches the declared state.

Think about promotion between environments as well. The goal is usually to promote a tested definition and artifact through controlled stages rather than rebuild a slightly different environment by hand. This reinforces consistency and makes the reason for a production difference easier to investigate.

Security and compliance belong inside delivery, not after it

The current exam expects DevOps engineers to incorporate security and compliance into the pipeline. Candidates should understand secrets, identities, service connections, access control, dependency or code scanning, policy enforcement, secure artifacts, and how to prevent credentials from leaking into repositories or logs.

Security automation should reduce unsafe manual handling without creating a false sense of protection. A passing scanner does not prove the application is secure. DevOps engineers need enough security judgment to decide what should block a deployment, what can be reviewed later, and how evidence should be retained for audit and incident investigation.

Practice identity and secret-management scenarios. Decide when a workload identity is safer than a stored credential, how service connections should be scoped, who can approve a production change, and what happens when a secret is exposed. The exam rewards designs that reduce standing privilege and make control boundaries visible.

Instrumentation closes the delivery feedback loop

A deployment is not complete when a pipeline reports success. Teams need telemetry that shows whether the change is healthy in production. AZ-400 therefore includes instrumentation and monitoring: logs, metrics, traces, dashboards, alerts, and the feedback that connects runtime behavior with engineering work.

Practice designing signals around user experience and service health rather than collecting every possible metric. A useful alert should lead to action. A useful dashboard should answer an operational question. The strongest DevOps solutions connect deployment events with the changes in system behavior that follow them.

Instrumentation also supports delivery improvement. Deployment frequency, lead time, failure rate, recovery time, queue age, and test behavior can reveal weaknesses in the delivery system itself. The point is not to maximize every metric independently; it is to understand where delivery becomes risky or slow and improve the constraint.

Connect operational feedback back to engineering work. A recurring incident should produce learning, a noisy alert should be improved, and a deployment pattern that repeatedly fails should trigger changes to the delivery system. Feedback has value only when it changes future behavior.

Prepare by building one complete delivery system

Instead of studying each objective as an isolated chapter, build a small application and take it through a complete workflow. Put the code in GitHub or Azure Repos. Apply branch policies. Build and test it automatically. Package an artifact. Define infrastructure as code. Deploy through environments. Add security checks. Instrument the application. Then deliberately break different parts and troubleshoot them.

This gives the exam vocabulary a working context. It also exposes the operational relationships that scenario questions are designed to test. A candidate who has only read about pipelines often struggles when several technically valid options appear in one question.

Use the blueprint to find weak domains, not to memorize percentages

The current weights tell you where the exam spends attention, but readiness is about capability. A candidate who is strong in pipelines but weak in source-control governance, security, or monitoring still has meaningful gaps. Use practice results to identify the reasoning behind mistakes and return to the relevant system, not just the missed question.

AZ-400 is strongest as a professional certification when preparation changes the way you deliver software. If you can explain how work flows from source control to a secure, observable production deployment—and can diagnose what happens when that flow fails—you are studying the role rather than merely studying the test.

A disciplined AZ-400 exam-day strategy stops expanding the tool list near the exam. Review the current blueprint, rehearse complete scenarios, and focus on weak decisions. The exam can mention GitHub, Azure DevOps, Azure services, or security controls, but the durable skill is choosing a delivery design that is traceable, repeatable, secure, and observable.

Scenario practice should therefore compare multiple valid implementations. Ask which option improves traceability, reduces manual risk, supports rollback, preserves least privilege, or produces better operational evidence. The best answer is often the design that improves the delivery system, not the one that uses the most advanced product feature.

A useful readiness check is whether you can draw a delivery system from memory and defend each control. Explain repository policy, build evidence, artifact handling, environment promotion, identity, secrets, deployment strategy, rollback, and production telemetry. If one part of the diagram depends on “the tool handles it,” return to that area until you understand the decision behind the feature.

Finally, verify that your labs include both GitHub and Azure DevOps. Microsoft’s current role description explicitly expects experience with both ecosystems. You do not need identical depth everywhere, but you should understand how core DevOps ideas map across the two toolchains.

Then redesign the same system with a different implementation choice—GitHub Actions instead of Azure Pipelines, or a different branching and promotion model. If your reasoning survives the tool change, you understand the DevOps principle. If it collapses, your knowledge may still be product memorization.

That cross-tool reasoning is especially important because Microsoft’s blueprint can evolve while the DevOps principles remain stable. Learn the operating model deeply enough that a feature rename or interface change does not invalidate your understanding.

This is the strongest protection against exam updates: principles survive product changes better than memorized screens.

That is the level of understanding a role-based expert certification is meant to validate.

It is also what makes the learning transferable beyond one Microsoft interface.