Microsoft Azure DevOps Engineer Expert [AZ-400] Exam Guide (2026)

If you can say whether a pipeline should run in GitHub Actions or Azure Pipelines, whether a release should swap an App Service slot or shift canary traffic, and whether the stem is buying a trunk, a feature branch, or a release branch, you are reading the right outline.

AZ-400 is the exam behind Microsoft Certified: DevOps Engineer Expert. The credential requires Azure Administrator Associate or Azure Developer Associate first. The exam page names the sitting Designing and Implementing Microsoft DevOps Solutions, marks the English language version updated on 27 July 2026, and publishes a passing score of 700. The study guide publishes the matching skills outline under the heading Skills measured as of July 27, 2026. That outline is the whole scope of the current sitting.

The sitting is live. Retirement date is none. The exam page publishes a Pearson VUE schedule path and a free practice assessment. Expert certifications expire annually and renew on a free, unproctored Microsoft Learn assessment. This guide is for people scheduling that July 2026 blueprint, who already hold the title and need the current task list, or who are moving from Azure administration or Azure development into the DevOps-engineer role.

Who this exam is for

Take it as a map of the Azure DevOps-engineer job Microsoft scores under this code. The audience profile asks for a developer or an infrastructure administrator who also has subject matter expertise working with people, processes, and products to enable continuous delivery of value. The five named areas are processes and communications, source control, build and release pipelines, security and compliance, and instrumentation.

The responsibility list is concrete. Deliver Microsoft DevOps solutions that provide continuous security, integration, testing, delivery, deployment, monitoring, and feedback. Design and implement flow of work, collaboration, communication, source control, and automation. Microsoft is explicit that the role sits with developers, site reliability engineers, Azure administrators, and security engineers. The candidate must have experience both administering and developing in Azure, with strong skills in at least one of those two, and must have implemented both GitHub and Azure DevOps solutions.

The prerequisite is a hard gate. Microsoft Certified: DevOps Engineer Expert requires Microsoft Certified: Azure Administrator Associate or Microsoft Certified: Azure Developer Associate. If subscriptions, role-based access, Policy, virtual machines, and App Service are still a catalog rather than weekly work, sit AZ-104 first. If the application the pipeline would build is still a catalog rather than weekly work, sit AZ-204 first. The expert sitting assumes those controls and then asks which pipeline, which deployment pattern, and which branch strategy to implement.

Skip it if the goal is the language of the cloud rather than the delivery of it. Service definitions, pricing models, and shared responsibility belong to AZ-900. Skip it if the work you actually want is running someone else's subscription day to day without owning the pipeline, the release, or the branch policy, because that job is AZ-104. Skip it if the work you actually want is writing the application without owning the release gates, because that job is AZ-204. Skip it if the work you actually want is hardening identity, compute, and posture without owning the YAML, the environment check, or the secretless federation, because that job is AZ-500. Those controls appear on this outline as the security half of automation. They are scored there as the whole job.

The current expert DevOps credential Microsoft publishes is this one. Use this page for the AZ-400 task list. Use the AZ-104 exam guide when the stem is an administrator control that happens to sit under a pipeline. Use the AZ-500 exam guide when the stem is a security control that happens to sit on a service connection. Use the AZ-305 exam guide when the stem is an architect recommendation for the host the pipeline deploys onto.

Exam shape and how the score works

The July 2026 outline has five functional groups, and Microsoft publishes weight ranges rather than fixed percentages.

Do the arithmetic on those ranges before building a plan. The lower bounds total 85%. The upper bounds total 110%. The midpoints total 97.5%. No exact split exists to memorize, and the bands are the only ordering Microsoft gives you. Build and release pipelines sits alone at the top. Processes, source control, and security sit together in the middle band. Instrumentation sits alone at the bottom. Any study plan that gives five equal weeks overweights telemetry and underweights YAML, agents, deployment patterns, and package feeds.

The logistics come off the credential page, the exam page, and the duration table. The sitting is scheduled through Pearson VUE. Price depends on the country or region where the exam is proctored, so no single global figure is published. Languages are English, Japanese, Chinese (Simplified), Korean, German, French, Spanish, Portuguese (Brazil), Chinese (Traditional), and Italian. A failed attempt can be retaken 24 hours later, and the wait varies for later retakes. Microsoft tells candidates to register with a personal MSA account, because an organizational account loses the exam record if the person leaves that organization.

The AZ-400 credential page and exam page opened for this guide do not publish a minutes figure. Microsoft's duration table lists associate and expert role-based exams without labs at 100 minutes of exam time and 120 minutes of seat time, and lists exams that may contain labs at 120 minutes of exam time and 140 minutes of seat time. Microsoft states plainly that it does not publish a list of exams with labs, because labs can be pulled at any time for an outage or a bandwidth problem, and that the real exam time is confirmed at registration and on the launch screens. Plan from the duration table. Do not invent a timer the exam page did not give you.

Scoring is the part most candidates get wrong. Technical exam scores are reported on a scale of 1 to 1,000 and 700 or greater passes. Microsoft says the scaled score may not equal 70% of the points. A passing score is based on the knowledge and skills needed to demonstrate competence as well as the difficulty of the questions. Multi-part questions usually award one point per correctly answered component, so all, some, or none of the points on a question are possible. There is no penalty for guessing. Some questions are unscored and used to collect data, and candidates are never told which, so every question deserves an answer.

The score report gives one overall number, a pass or fail status, and a bar chart per skill area. It does not give a numeric score per section, and Microsoft warns that the bars cannot be added up to reconstruct the result. A short bar in a small area can mean a handful of questions went wrong, and scoring zero in an area that carries only a few questions is documented as normal. Instrumentation at 5 to 10% is the area where a short bar is easiest to misread as a catastrophe.

Two more details change how the sitting is taken. Microsoft Learn is available in a split screen during role-based exams, covering everything on learn.microsoft.com except Q&A, practice assessments, and your profile, with no extra time added and no navigation outside the domain. Five minutes of break time are built into the clock, questions were removed to make room for it, and any question you have already seen is gone once the break starts.

The credential itself follows the expert renewal rule. Expert certifications expire annually. Renewal is free, unproctored, open book, and shorter than the original exam, inside a six month window before expiry. Passing extends the certification one year from the expiration date.

What changed on 27 July 2026

The study guide publishes a change log comparing the previous outline with the current one. The full table is short.

Three things are true of that table, and each one changes what you should do with older study material.

Every functional group listed is marked No change. Nothing on the table is marked Major. The exam code did not move, the five areas did not move, and the published weight ranges are the ones above. AZ-400 material written against the previous outline is still structurally correct.

Every sub-area listed is marked Minor. The touched sub-areas are traceability and flow of work, automate security and compliance scanning, configure monitoring for a DevOps environment, and analyze metrics from instrumentation. Those are the places Azure has been adding GitHub Issues and Boards integration, GitHub Advanced Security packaging, Defender for Cloud DevOps Security, and Application Insights OpenTelemetry. Treat them as refresh work rather than relearning. Microsoft adds that most questions cover features that are generally available, and that preview features can appear when they are commonly used.

The table carries no row at all for source control strategy or for build and release pipelines. Those are the areas that decide GitHub Actions against Azure Pipelines, a Microsoft-hosted agent against a self-hosted runner, a slot swap against a canary shift, and a trunk against a release branch. Those controls behave on the current exam the way they behaved on the previous one, which makes those areas the cheapest place to bank points and the least excusable place to lose them.

The English-language update date on the exam page is 27 July 2026, the same date the study guide uses for skills measured. Use that date for the outline. Localized versions update about eight weeks later. If the exam is not available in a preferred language, Microsoft lets the candidate request an additional 30 minutes.

How a pipeline host gets picked

Build and release pipelines are 50 to 55%, the change log skipped them, and the same discriminator shows up in agent stems, YAML stems, and GitHub-integration stems as often as in Actions ones.

Microsoft's DevOps start-here page files Azure Pipelines and GitHub Actions in the same CI/CD set, and each one has its own job. Read the control the stem is buying before reading the options.

Azure Pipelines is the Azure DevOps service that combines continuous integration, continuous testing, and continuous delivery. It builds, tests, and deploys to virtual machines, environments, containers, on-premises and cloud platforms, and PaaS. It speaks YAML. It can consume Azure Repos or GitHub. It can publish NuGet, npm, Maven, or Python packages to Azure Artifacts. A stem about multi-stage YAML, an environment check that is not in the YAML file, a service connection, or a classic-to-YAML migration is an Azure Pipelines stem.

GitHub Actions automates software workflows directly from a GitHub repository. Native CI/CD, testing, and deployment live next to the pull request. A stem about a workflow file under .github/workflows, a GitHub-hosted runner label, GITHUB_TOKEN, or an environment secret that waits on a reviewer is a GitHub Actions stem. A stem that wants Azure Boards work-item traceability, Azure Artifacts views, or an Azure DevOps agent pool is not.

The two hosts also combine. Azure Pipelines can automatically build, test, package, and deploy a GitHub repository and write status back onto the pull request. The outline names that integration as its own task. A stem that keeps the code on GitHub and the release on Azure DevOps is asking for that pairing, not for a forced move of the repo.

The runner is a second question on the same band. An agent is computing infrastructure that runs one job at a time.

Microsoft-hosted agents are hosted and managed by Microsoft on Azure DevOps Services. Each job gets a fresh virtual machine from the Azure Pipelines pool. The machine is discarded when the job ends. The image is the latest version of the one you named. Microsoft says to try this first. A stem about a clean image, no leftover files, and no custom software is a Microsoft-hosted stem.

Self-hosted agents are machines you configure and manage. Caches and installed tools persist from run to run. Microsoft strongly recommends one agent per machine. A stem about a licensed compiler, a private network path, or a cache that must survive the next job is a self-hosted stem.

GitHub-hosted agents for Azure Pipelines are a third option on Azure DevOps Services. They run on GitHub-hosted infrastructure and bill per minute. Microsoft documents them as more powerful than the concurrency-based Microsoft-hosted pool. Managed DevOps Pools are the managed custom-pool path. The virtual machines live in a Microsoft subscription, not in yours. Azure Virtual Machine Scale Sets agents still exist. Microsoft now points new custom pools at Managed DevOps Pools.

YAML environment checks sit on this host question even when the stem looks like a release question. Approvals and other checks are not written in the YAML file. Resource owners set them on environments, service connections, agent pools, variable groups, and secure files. A stage waits until every check on every resource it consumes has passed. Static checks run first, then pre-check approvals, then dynamic checks, then post-check approvals, then the exclusive lock. If a group is the approver, one member is enough. A timeout skips the stage. Classic release pre-deployment and post-deployment approvals are a different surface. The outline asks you to migrate classic to YAML, and it asks you to implement checks on YAML-based environments. Treating the classic approval pane as the YAML answer is how that question is lost.

Read the constraint the stem is buying. Code and workflow on GitHub, with no Azure DevOps project in the story, is GitHub Actions. An Azure DevOps project, an environment check, or a service connection is Azure Pipelines. A GitHub repo that must report into Azure Pipelines is the integration path. A clean VM that disappears after the job is Microsoft-hosted. A tool that must stay installed is self-hosted.

How a deployment pattern gets picked

Deployments sit inside the same 50 to 55% band, the change log skipped them, and most of their questions reduce to one skill. Name whether the stem is buying two full pools, a small first audience, a warm slot, or a flag that does not redeploy the code.

Microsoft's Well-Architected safe-deployment guide sorts the patterns on blast radius, and App Service slots and App Configuration Feature Manager are the Azure implementations the outline names.

Blue-green keeps two identical pools. Blue serves everyone. Green is updated and tested, then traffic moves across in waves. After the rollout finishes, the pools change roles. Bake time between waves is measured in hours and days, not minutes. A stem about two production-sized environments and a load balancer that can point at either one is blue-green. Using one half-size staging VM as "green" is the trap.

Canary is progressive exposure. A small internal or external group gets the new version first. Feature flags are the usual way to turn that version on for the group. If health stays green through the bake time, the next group is added. If a health signal trips, the rollout stops. Recovery is rollback, a hotfix that rolls forward, or new infrastructure from the last known good configuration. A stem about 5% of users, then 25%, then everyone, is canary. A stem about two full fleets and a DNS cut is not.

Ring deployments are the geographic form of the same idea. Microsoft's classic release example promotes Dev, then parallel QA, then Prod ring 1, then Prod ring 2, and each production ring is the same web app in a different geography. A ring is a stage. It is not a second color of a blue-green pair. The outline still asks you to migrate classic to YAML. The ring idea survives. The classic designer does not have to.

Deployment slots are the App Service form of a warm swap. They exist on Standard, Premium, and Isolated. Each slot is a live app with its own host name. The swap warms every instance on the source slot, then switches routing. Production stays online if production is the target. No requests drop because of the swap. After the swap, yesterday's production sits in the former staging slot, so a second swap is the rollback. There is no extra charge for a slot. Standard allows five. An app that already has six slots cannot scale down to Standard. Auto swap exists when pre-swap validation is not needed. App settings and connection strings can be marked to stick to a slot. A stem about an App Service on Premium that must not drop requests is a slot stem. A stem about a percentage of users inside one app is a flag stem.

Feature flags live in Azure App Configuration Feature Manager. Switch is on or off for everyone. Rollout is a percentage, a group, a user, or a schedule. Experiment is A/B or multivariate traffic across variants. The outline names Feature Manager as the implementation. A stem about turning a feature on for the beta group without a new deploy is a flag. A stem about a broken package that must leave production is a slot swap or a blue-green cut, not a flag.

A hotfix has its own path. Well-Architected tells you to write emergency protocols that can shorten approvals, smoke tests, and bake time, and to name who can approve that acceleration. The outline asks for a hotfix path for high-priority code fixes. Treating a hotfix as a reason to skip the environment check entirely is the trap. The check can be faster. It is still a check.

Azure Deployment Environments is still on the July 2026 outline as the on-demand self-deployment answer. Platform engineers curate templates. Developers deploy those templates into subscriptions they can reach. Microsoft states that the service retires on 22 February 2027 and that workflows should move to a Microsoft service, an Azure service, or a partner solution by that date. Use it when the stem is on-demand self-deployment on this blueprint. Do not invent a replacement the exam page did not name.

Read the constraint the stem is buying. Two full fleets and a cut is blue-green. A small first audience is canary. A warmed App Service hostname is a slot. A behavior change that must not redeploy is a flag. A broken production binary is not a flag.

How a branch strategy gets picked

Source control is 10 to 15%, the change log skipped it, and the same discriminator shows up in pipeline stems and hotfix stems as often as in Git ones.

Microsoft's Azure Repos guidance and the Well-Architected safe-deployment guide sort the strategies on how close the work stays to main, and GitHub Flow is the named flow-of-work structure in the processes group.

Keep the strategy simple. Microsoft's three concepts are feature branches for new work and fixes, pull requests into main, and a main branch that always builds. Even a small fix gets its own branch. Two reviewers is the number Microsoft cites from research. A branch policy on main should require the pull request, add reviewers, and require a successful build. Merging to main without a pull request is the failure the policy exists to stop.

Trunk-based development, named on the outline and recommended by Well-Architected next to Release Flow, keeps work on or next to main. Branches are short. Integration happens every day. Well-Architected is explicit that this is the structure to use, and that Gitflow and environment-based branching are the ones to avoid. A stem about many developers merging small changes to main several times a day is trunk-based. A stem about develop, release, and hotfix as long-lived lines is Gitflow, and it is the wrong answer on this blueprint.

Feature branches isolate work in progress. Name them by convention. Merge them only through a pull request that passed review and a build. GitHub Flow is this shape with the extra closing step of deleting the branch after merge. Create a branch, make the change, open the pull request, address review, merge, delete the branch. A separate branch for each unrelated change. Branch protection can block a merge that lacks the required reviews. A stem about GitHub Flow is a feature-branch stem with that close-out rule, not a release-branch stem.

Release branches stabilize a shipped line. They are long-lived. They are not merged back into main as a pull request. Create one from main near a release. Fix the release on that branch. Port the fix back to main with a cherry-pick, not with a merge of the whole release branch, because a merge brings release-only commits you do not want on main. The Azure DevOps team's own Release Flow does the reverse port: change on main, then cherry-pick onto the release branch. Lock the release branch when support ends. Tags can mark a commit. Microsoft says tags are easy to miss and add a push that people forget. A release branch is the workflow the guidance prefers for a supported line.

Large files and history cleanup are their own bullets. Git LFS and git-fat are the named large-file tools. Scalar is the named scale tool. Tags organize the repo. Recovering a commit and removing a secret from history are both on the outline. Removing a secret from the current file and leaving it in history is how the GHAS push-protection question is lost.

Read the constraint the stem is buying. Daily merges onto a protected main are trunk-based. A reviewed topic branch that is deleted after merge is GitHub Flow. A supported 20.4 line that must not take unrelated main commits is a release branch. An environment named deploy/prod used as a long-lived branch is the environment-based pattern Well-Architected told you not to use.

How to study the July 2026 blueprint

Order the weeks by the weight bands, not by the order the areas are printed in.

Week 1. Pipeline hosts, the first half of the 50 to 55% area. Create one GitHub repository and one Azure DevOps project. Write a GitHub Actions workflow that builds on a GitHub-hosted runner. Write an Azure Pipelines YAML pipeline that builds the same repo on a Microsoft-hosted agent. Then point Azure Pipelines at the GitHub repository and confirm the pull request gets a status. Stand up a self-hosted agent on a small virtual machine, install one extra tool, run the same job twice, and write down that the tool is still there on the second run. Create an environment, add a manual approval check and a branch-control check, and confirm that neither check appears in the YAML. Create a variable group and a secure file and attach a check to each. Write a multi-stage YAML pipeline with a template, a variable group, and a stage that consumes that environment. Fail the approval once and watch the stage skip on timeout. Publish a package to Azure Artifacts with SemVer, then to GitHub Packages, and write down which view or visibility control each feed used.

Week 2. Deployments, IaC, and pipeline maintenance, the rest of the 50 to 55% area. Deploy one App Service on Standard. Create a staging slot, deploy a build to it, swap with production as the target, then swap back. Mark one app setting as slot-specific and confirm it did not ride the swap. Create an App Configuration store. Make one Switch flag, one Rollout flag at 10%, and one Experiment flag with two variants. Flip the Switch without a new deploy. Draw a blue-green pair and a canary sequence on paper and name the bake time you would wait. Write a hotfix path that shortens the approval timeout without deleting the check. Define one Bicep file and one ARM template for the same web app, then assign a Machine Configuration audit to a test virtual machine. Open Azure Deployment Environments long enough to say it is the on-demand template answer on this outline and that Microsoft publishes a 22 February 2027 retirement. Convert one classic release pipeline to YAML. Read failure rate, duration, and one flaky test on a pipeline run, then set a retention policy on the artifacts.

Week 3. Source control and processes, 10 to 15% stacked with 10 to 15%. Protect main with a pull request policy, required reviewers, and a build validation. Create a feature branch, open a pull request, and merge only after the build is green. Create a release/20.4 branch, cherry-pick one commit from main, and write down why a merge of the whole release branch would have been wrong. Turn on Git LFS for one binary. Add a tag. Practice recovering a commit and removing a file from history in a throwaway repo. Then build the process side. Create a GitHub Issue and an Azure Boards work item and link both to the same pull request. Connect Azure Boards to the GitHub repository. Create a wiki page in Markdown with a Mermaid diagram. Post a webhook into Microsoft Teams for a completed run. Build a dashboard that shows cycle time, lead time, and time to recovery.

Week 4. Security and instrumentation, 10 to 15% stacked with 5 to 10%, and a full review. Create a user-assigned managed identity and a workload-identity-federation service connection. Create the matching federated credential for a GitHub Actions workflow that logs in with OpenID Connect and id-token: write. Store a secret, a key, and a certificate in Key Vault and read them from the pipeline without printing them. Put a dummy secret in a file, push, and watch GHAS push protection or secret scanning catch it. Enable GitHub Advanced Security on an Azure Repos Git repository if you have Azure DevOps Services, and write down that a GitHub repository uses GitHub Advanced Security, not the Azure DevOps product. Turn on Dependabot alerts. Connect the repo to Defender for Cloud DevOps Security and read one code finding, one secret finding, and one dependency finding. Create an Application Insights resource, emit a trace, open the application map, and write one KQL query against the logs. Turn on VM Insights or Container Insights on the host from week 2. Create one alert on a failed GitHub Actions run and one alert on a failed Azure Pipelines run. Spend the rest of the week rereading the study guide task statements and naming, for each bullet, the host, the pattern, or the branch that would answer it.

Take the free practice assessment linked from the exam page and run the exam sandbox at least once before using this outline against a clock. The sandbox exists so the question formats cost you nothing on the timer.

Traps that look like easy elimination

Expert items rarely give one plausible answer and three absurd ones. They give two controls that both sound correct and one detail that picks between them.

• Azure Administrator Associate or Azure Developer Associate is required for the Expert credential. Passing AZ-400 without one of those associate certifications does not complete the title.
• GitHub Actions lives in the GitHub repository. Azure Pipelines lives in the Azure DevOps project. A GitHub repo can still feed Azure Pipelines. That pairing is a named task, not a reason to treat the two hosts as the same product.
• Microsoft-hosted agents are a fresh virtual machine per job. Self-hosted agents keep their disks and their tools. One agent per machine is the Microsoft recommendation.
• Managed DevOps Pools put the VMs in a Microsoft subscription. Scale-set agents still exist. New custom pools should start at Managed DevOps Pools.
• YAML environment checks are not in the YAML file. Resource owners set them. Classic pre-deployment approvals are a different surface.
• If a group is the approver, one member is enough. A timeout skips the stage.
• Blue-green needs two full-size pools. A half-size staging box is not green.
• Canary is a small first audience. Feature flags are the usual switch. Bake time is hours and days.
• A ring is a geographic stage. It is not a second color of a blue-green pair.
• App Service slots need Standard, Premium, or Isolated. Production must be the target of the swap so production stays up. A second swap is the rollback.
• Standard allows five slots. An app with six slots cannot scale down to Standard.
• Slot-specific app settings stay in the slot. Settings that are not marked that way ride the swap.
• Feature Manager Switch is everyone. Rollout is a percentage. Experiment is A/B. A flag does not replace a broken binary.
• A hotfix can shorten a check. It does not delete the check.
• Azure Deployment Environments is still the on-demand answer on this outline. Microsoft publishes a 22 February 2027 retirement.
• Trunk-based and Release Flow are the Well-Architected recommendation. Gitflow and environment branches are the ones to avoid.
• Feature branches merge through pull requests. Release branches are long-lived and take cherry-picks, not a merge back into main.
• GitHub Flow deletes the branch after merge. That close-out does not make it a release-branch strategy.
• Tags mark a commit. Microsoft prefers a release branch for a supported line because tags are easy to miss.
• Workload identity federation is the recommended Azure Pipelines connection. A client secret is the compatibility path.
• The Azure DevOps token issuer for workload identity federation retires on 1 July 2027. New connections use the Microsoft Entra issuer.
• GitHub Actions OIDC needs a federated credential and id-token: write. It does not need a client secret in the recommended path.
• System-assigned and user-assigned managed identities are both on the outline. A service principal is the other choice, not a third kind of managed identity.
• GITHUB_TOKEN is the job token. A personal access token is a person. A GitHub App is an app. They are three answers.
• Stakeholder access is the Azure DevOps limited seat. Outside collaborator is the GitHub limited seat. They are not interchangeable names.
• Key Vault Standard is software-protected keys. Premium is HSM-protected keys at FIPS 140-3 Level 3. Authentication is Entra ID. Azure RBAC can govern the vault and the data. A vault access policy can govern only the data.
• GitHub Advanced Security for Azure DevOps is Azure Repos Git on Azure DevOps Services. A GitHub repository uses GitHub Advanced Security.
• Secret scanning push protection blocks future pushes. Repository scanning finds secrets already in history. Removing the file and leaving the commit is not a clean-up.
• Dependency scanning is pipeline-based. Enabling the product does not, by itself, scan every branch.
• CodeQL default setup does not cover Go or Swift. Those need advanced setup.
• Defender for Cloud DevOps Security sees Azure DevOps, GitHub, and GitLab. GHAS on Azure DevOps does not see GitLab.
• Dependabot is the named open-source alert path. It is not a substitute for CodeQL.
• Application Insights traces the application. VM Insights traces the guest. Container Insights traces the cluster. Azure Monitor Logs is where basic KQL runs.
• Instrumentation at 5 to 10% can still show a zero on the score bar. Microsoft documents that as normal for a small area.

If deleting the scenario still lets you pick the answer from the service name, the question is easier than the live exam.

How this maps to CloudFluently

Start with the official material. The Microsoft Certified: DevOps Engineer Expert credential page carries the audience profile, the AZ-104 or AZ-204 prerequisite, and the renewal path. The Exam AZ-400 page carries the 27 July 2026 English update, the 700 passing score, the practice assessment, and the exam sandbox. The study guide for Exam AZ-400 carries the task statements, the weight ranges, and the change log quoted above. Exam duration and exam experience explains the expert timer, the built-in break, and the Microsoft Learn split screen. Exam scoring and score reports explains the 700 scaled pass mark and why that scaled score may not equal 70% of the points. Microsoft Certification renewal explains the annual free assessment.

AZ-400 sits on top of Azure fundamentals, Azure administration, and Azure development, and that ground is already live here. Shared responsibility, regions, and the management-group idea are the AZ-900 Azure Fundamentals study notes and the AZ-900 Azure Fundamentals practice exam sets. The Azure Fundamentals roadmap sequences that ground, and the AZ-900 exam guide is the first companion page. Subscriptions, RBAC, Policy, virtual machines, and App Service are the AZ-104 exam guide and the Azure Administrator roadmap. The application the pipeline builds is the Azure Developer roadmap. The Azure DevOps roadmap sequences the expert sitting this page maps.

The security-engineer and architect readings of the same controls are already live as well. Key Vault, managed identities, and Defender for Cloud are the AZ-500 exam guide. App Service slots, compute shape, and the host a pipeline deploys onto are the AZ-305 exam guide.

Work those until the platform, the administrator controls, the developer path, the security controls, and the architect host recommendations are automatic, then use this page and the official study guide for the DevOps-engineer-only skills: GitHub Actions against Azure Pipelines, a hosted agent against a self-hosted runner, blue-green against canary against a slot against a flag, and a trunk against a feature branch against a release branch.

Frequently Asked Questions

What is the passing score for AZ-400? 700 or greater on a scale of 1 to 1,000. Microsoft states that this is a scaled score and that it may not equal 70% of the points, because a passing score is based on the knowledge and skills needed to demonstrate competence as well as the difficulty of the questions.

How long is the exam and how many questions are there? The AZ-400 credential page and exam page do not publish a minutes figure. Microsoft's duration table lists expert role-based exams without labs at 100 minutes, and exams that may contain labs at 120 minutes. The exam time is confirmed at registration and on the launch screens. Microsoft does not publish a question count for any individual exam, and says most certification exams typically contain between 40 and 60 questions.

Does AZ-400 have labs? Microsoft does not publish a list of exams with labs, because labs can be removed at any time for outages or bandwidth issues. The exam time is confirmed at registration and on the launch screens.

Does AZ-400 complete the Expert credential on its own? No. Microsoft Certified: DevOps Engineer Expert requires Microsoft Certified: Azure Administrator Associate or Microsoft Certified: Azure Developer Associate, and Exam AZ-400.

What changed on 27 July 2026? Every functional group on the change log is marked No change, and every listed sub-area is marked Minor. The touched sub-areas are traceability and flow of work, automate security and compliance scanning, configure monitoring, and analyze metrics. The change log carries no row for source control strategy or for build and release pipelines.

Which skill area is heaviest? Design and implement build and release pipelines is the top band at 50 to 55%. Processes, source control, and security each sit at 10 to 15%. Implement an instrumentation strategy is lowest at 5 to 10%.

Why do the percentages not add up to 100? Because Microsoft publishes ranges. The lower bounds total 85% and the upper bounds total 110%. The midpoints total 97.5%, and that still does not pin an exact split. Use the bands to order study time.

Can I use Microsoft Learn during the exam? Yes, on role-based exams. The split screen covers learn.microsoft.com, minus Q&A, practice assessments, and your profile. No extra time is added, the clock keeps running, and navigation to other domains is blocked.

How long does the certification last? Expert certifications expire annually. Renewal is free, online, unproctored, and open book, with a six month window before expiry. Passing extends the certification one year from the expiration date.

Can I retake it if I fail? A failed attempt can be retaken 24 hours after the first attempt. Waiting periods for later retakes vary.

How does AZ-400 relate to AZ-104, AZ-500, and AZ-305? AZ-104 is one of the two required associate credentials and scores the administrator controls the pipeline deploys onto. AZ-204 is the other required associate credential. AZ-500 scores the security controls that sit on a service connection or a vault. AZ-305 scores the architect recommendation for the host. AZ-400 scores the delivery system: the pipeline host, the deployment pattern, and the branch strategy. The official outline is the study guide for Exam AZ-400. Use Microsoft for the task statements and the weight ranges. Use this page for what changed, what the discriminators are, and how to sequence the July 2026 blueprint.