AZ-400: Designing and Implementing Microsoft DevOps Solutions
Over half this exam lives in one domain: build and release pipelines. This guide maps all five official domains straight from Microsoft Learn into a 4-week plan weighted the way the exam actually is — plus the five architecture trade-offs that separate a pass from a fail.
Exam Snapshot
- Level
- Expert
- Questions
- ~40–60
- Duration
- 120 minutes
- Passing score
- 700 / 1000
- Cost
- $165 USD
- Domains
- 5
- Prerequisite
- AZ-104 or AZ-Dev Associate
What Is the AZ-400 Exam?
AZ-400 (Designing and Implementing Microsoft DevOps Solutions) is Microsoft's Expert-level exam for the DevOps Engineer Expertcertification. Per Microsoft's audience profile, you're a developer or infrastructure administrator with subject-matter expertise in people, process, and product — responsible for continuous integration, delivery, deployment, security, and feedback, across both GitHub and Azure DevOps.
The exam assumes you already have hands-on Azure experience. That is exactly why the certification requires an active AZ-104 (Azure Administrator Associate) or Azure Developer Associate certification alongside passing AZ-400 — Microsoft is testing process design on top of infrastructure knowledge it expects you to already hold, not teaching that infrastructure knowledge from scratch.
If you're newer to GitHub specifically, GH-900 (GitHub Foundations) is a reasonable on-ramp for terminology — but it will not prepare you for the architecture-level pipeline and deployment-strategy questions AZ-400 actually asks.
The Domain Pipeline
Five domains, straight from Microsoft's official skills-measured outline. Domain 3 is expanded by default below because it is more than half the exam — the rest are one click away.
Domain 1: Design and implement processes and communications
10–15%View sub-skills↓
Design and implement traceability and flow of work
- • Design a structure for the flow of work, including GitHub Flow
- • Design a strategy for feedback cycles, including notifications and GitHub Issues
- • Design integration for tracking work, including GitHub projects, Azure Boards, and repositories
- • Design source, bug, and quality traceability
Design appropriate metrics and queries for DevOps
- • Design a dashboard covering flow of work — cycle time, time to recovery, and lead time
- • Design metrics and queries for planning, development, testing, security, delivery, and operations
Configure collaboration and communication
- • Document a project using wikis and process diagrams, including Markdown and Mermaid syntax
- • Configure release documentation, including release notes and API documentation
- • Automate documentation creation from Git history
- • Configure integration by using webhooks
- • Configure integration between Azure Boards and GitHub repositories
- • Configure integration between GitHub or Azure DevOps and Microsoft Teams
Domain 2: Design and implement a source control strategy
10–15%View sub-skills↓
Design branching strategies for the source code
- • Design a branch strategy, including trunk-based, feature branch, and release branch
- • Design a pull request workflow by using branch policies and branch protection rules
- • Implement branch merging restrictions by using branch policies and branch protection rules
Configure and manage repositories
- • Design a strategy for managing large files, including Git LFS and git-fat
- • Design a strategy for scaling and optimizing a Git repository, including Scalar and cross-repository sharing
- • Configure permissions in the source control repository
- • Configure tags to organize the source control repository
- • Recover specific data by using Git commands
- • Remove specific data from source control
Domain 3: Design and implement build and release pipelines
50–55%Design a package management strategy
- • Recommend package management tools, including GitHub Packages and Azure Artifacts
- • Design package feeds and views for local and upstream packages
- • Design a dependency versioning strategy, including SemVer and date-based (CalVer)
- • Design a versioning strategy for pipeline artifacts
Design a testing strategy for pipelines
- • Design quality and release gates, including security and governance
- • Design a comprehensive testing strategy — unit, integration, and load tests
- • Implement tests in a pipeline, including test tasks, test agents, and result integration
- • Implement code coverage analysis
Design and implement pipelines
- • Select a deployment automation solution — GitHub Actions or Azure Pipelines
- • Design a GitHub runner or Azure DevOps agent infrastructure
- • Design integration between GitHub repositories and Azure Pipelines
- • Develop pipeline trigger rules
- • Develop pipelines by using YAML
- • Design a strategy for job execution order, including parallelism and multi-stage pipelines
- • Develop complex pipeline scenarios — hybrid pipelines, VM templates, self-hosted runners or agents
- • Create reusable pipeline elements — YAML templates, task groups, variables, variable groups
- • Design checks and approvals by using YAML-based environments
Design and implement deployments
- • Design a deployment strategy — blue-green, canary, ring, progressive exposure, feature flags, A/B testing
- • Design a pipeline ensuring dependency deployments are reliably ordered
- • Plan to minimize downtime — load balancing, rolling deployments, slot usage and swap
- • Design a hotfix path plan for high-priority code fixes
- • Design a resiliency strategy for deployment
- • Implement feature flags by using Azure App Configuration Feature Manager
- • Implement application deployment using containers, binaries, and scripts
- • Implement a deployment that includes database tasks
Design and implement infrastructure as code (IaC)
- • Recommend a configuration management technology for application infrastructure
- • Define an IaC strategy, including source control and automation of testing and deployment
- • Design desired state configuration — Azure Automation State Configuration, ARM, Bicep, Machine Configuration
- • Design Azure Deployment Environments for on-demand self-deployment
Maintain pipelines
- • Monitor pipeline health — failure rate, duration, flaky tests
- • Optimize a pipeline for cost, time, performance, reliability, and concurrency
- • Design a retention strategy for pipeline artifacts and dependencies
- • Migrate a pipeline from classic to YAML in Azure Pipelines
Domain 4: Develop a security and compliance plan
10–15%View sub-skills↓
Design authentication and authorization methods
- • Choose between Microsoft Entra service principals and managed identities (system- and user-assigned)
- • Implement GitHub authentication — GitHub Apps, GITHUB_TOKEN, personal access tokens
- • Implement Azure DevOps service connections and personal access tokens
- • Design permissions and roles in GitHub and Azure DevOps
Manage sensitive information in automation
- • Implement secrets, keys, and certificates by using Azure Key Vault
- • Implement secretless authentication (e.g. workload identity federation/OIDC) in GitHub Actions and Azure Pipelines
- • Design a strategy for managing sensitive files during deployment, including Azure Pipelines secure files
- • Design pipelines to prevent leakage of sensitive information
Automate security and compliance scanning
- • Design a strategy for dependency, code, secret, and licensing scanning
- • Configure Microsoft Defender for Cloud DevOps Security
- • Configure GitHub Advanced Security for GitHub and for Azure DevOps
- • Automate container scanning, including CodeQL analysis in a container
- • Automate analysis of open-source vulnerabilities by using Dependabot alerts
Domain 5: Implement an instrumentation strategy
5–10%View sub-skills↓
Configure monitoring for a DevOps environment
- • Configure Azure Monitor and Azure Monitor Logs to integrate with DevOps tools
- • Configure telemetry collection — Application Insights, VM/Container/Storage/Network Insights
- • Configure monitoring in GitHub, including insights and charts
- • Configure alerts for events in GitHub Actions and Azure Pipelines
Analyze metrics from instrumentation
- • Inspect infrastructure performance indicators — CPU, memory, disk, network
- • Analyze metrics using collected telemetry, including usage and application performance
- • Inspect distributed tracing by using Azure Monitor Application Insights
- • Interrogate logs using basic Kusto Query Language (KQL) queries
Five Architecture Trade-Offs the Exam Tests
AZ-400 rarely asks “what does this feature do.” It asks “which of these two similar-sounding approaches fits this specific constraint” — these five comparisons account for a disproportionate share of missed questions.
01
Canary vs. Ring-Based vs. Blue-Green
Canary routes a small slice of live traffic to a new version to catch regressions early. Ring-based deployment is the organizational version of the same idea — internal ring, then early-adopter ring, then everyone — controlling who gets a build, not just what percentage of traffic. Blue-green keeps two full identical environments and swaps traffic instantly, prioritizing a fast, low-risk rollback over gradual exposure. A scenario asking for "instant rollback if anything looks wrong" wants blue-green; one asking for "test with a small internal group before anyone else sees it" wants rings.
02
Feature Flags vs. Deployment Rings
Both control exposure, but at different layers. A deployment ring controls which population receives a given build. A feature flag (via Azure App Configuration Feature Manager) controls which users see a given code path inside a build everyone already has. Flags decouple deployment from release — you can ship dark code to 100% of rings and still turn the feature on for 1% of users. A scenario needing to "turn a feature off instantly without a redeploy" always wants a flag, never a ring.
03
Managed Identity vs. Service Principal vs. OIDC/Workload Identity Federation
A managed identity is Azure-issued and tied to an Azure resource — no credential to store at all, but it only works for Azure-to-Azure calls. A service principal with a client secret works from anywhere (including GitHub Actions) but is a credential you must rotate and can leak. Workload identity federation (OIDC) gives GitHub Actions or Azure Pipelines a short-lived, federated token instead of a stored secret — the secretless option for external CI/CD calling into Azure. The exam's "no credential to manage" language almost always points to managed identity (Azure-native) or OIDC (external CI/CD), never a bare service principal secret.
04
Git LFS vs. Scalar
Git LFS solves large individual files (binaries, assets) by storing pointers in Git and the actual content elsewhere. Scalar solves large repositories — thousands of files, deep history, monorepos — by optimizing clone and checkout performance (sparse-checkout, background maintenance) regardless of file size. A scenario about "our design team keeps committing 200MB video files" is LFS; one about "our monorepo takes 40 minutes just to clone" is Scalar. They solve adjacent but distinct scaling problems and can both be tested in the same source-control-strategy scenario.
05
Dependabot vs. CodeQL vs. Defender for Cloud DevOps Security
Dependabot alerts scan your dependency graph for known vulnerabilities in third-party packages. CodeQL performs static analysis on the code you actually wrote, finding vulnerability patterns (like injection flaws) at the source level. Defender for Cloud DevOps Security is the unified posture layer sitting above both — connecting GitHub and Azure DevOps to surface exposed secrets, misconfigurations, and open-source risk in one Defender for Cloud view. A scenario naming a specific scan target (dependencies vs. first-party code) wants Dependabot or CodeQL; one asking for "a single security posture view across both platforms" wants Defender for Cloud DevOps Security.
4-Week AZ-400 Study Plan
Weeks 2 and 3 both live inside Domain 3 on purpose — it's 50–55% of the exam, so it gets half the plan.
Processes, Communications & Source Control (Domains 1–2)
- • Configure GitHub Issues notifications, GitHub projects, and Azure Boards integration for end-to-end work-item traceability
- • Build a flow-metrics dashboard covering cycle time, lead time, and time to recovery using Azure DevOps Analytics
- • Write a project wiki page using Markdown and a Mermaid diagram; configure a webhook and a Teams integration
- • Design a branch strategy (trunk-based vs. feature-branch vs. release-branch) for three different team sizes, then implement branch policies enforcing it
- • Configure Git LFS for a repo with binary assets, then practice recovering deleted commits and purging a leaked secret from history
Build & Release Pipelines, Part 1 — Package Management, Testing, Core YAML (Domain 3)
- • Set up an Azure Artifacts feed with local and upstream views; design a SemVer vs. CalVer strategy for two different package types
- • Implement quality gates and release gates in a pipeline; add unit, integration, and code-coverage tasks
- • Write a multi-stage YAML pipeline with parallel jobs, then extract shared logic into a reusable YAML template with variable groups
- • Configure a self-hosted agent and design a hybrid pipeline scenario deploying to both cloud and on-prem targets
Build & Release Pipelines, Part 2 — Deployment Strategy, IaC, Maintenance (Domain 3 continued)
- • Implement a canary deployment, a ring-based rollout, and a blue-green swap for the same app — compare rollback time for each
- • Add a feature flag via Azure App Configuration Feature Manager and toggle it independently of a deployment
- • Write a Bicep template for desired state configuration, then provision an on-demand environment using Azure Deployment Environments
- • Migrate a classic release pipeline to YAML; set up pipeline health monitoring for failure rate and flaky-test detection
Security, Compliance, Instrumentation + Full Review (Domains 4–5 + mock exams)
- • Replace a service-connection secret with workload identity federation (OIDC) in a GitHub Actions workflow calling Azure
- • Store a deployment secret in Key Vault, then enable GitHub Advanced Security (CodeQL + Dependabot) and connect it to Defender for Cloud DevOps Security
- • Configure Application Insights distributed tracing across two services and write a basic KQL query to isolate failed requests
- • Two full-length mock exams (120 minutes each); review every miss, then re-test the weakest domain the next day — prioritize Domain 3 misses since it is over half the exam
Frequently Asked Questions
What is the AZ-400 exam?+
AZ-400 (Designing and Implementing Microsoft DevOps Solutions) is Microsoft's Expert-level exam for the DevOps Engineer Expert certification. It tests whether you can design — not just operate — the DevOps process itself: source control strategy, CI/CD pipeline architecture, deployment patterns, security scanning, and instrumentation, across both GitHub and Azure DevOps.
What is the prerequisite for AZ-400?+
There is no enforced prerequisite to register for the exam itself, but the DevOps Engineer Expert certification requires you to also hold an active Azure Administrator Associate (AZ-104) or Azure Developer Associate certification. Microsoft designed AZ-400 assuming that operational or development Azure background already exists, so most candidates take AZ-104 first — see our AZ-104 study guide below if you haven't.
What is the single largest domain on AZ-400?+
Design and implement build and release pipelines, at 50–55% of the exam — more than the other four domains combined. It covers package management, pipeline testing, YAML pipeline authoring, deployment strategy, infrastructure as code, and pipeline maintenance. Any AZ-400 study plan that doesn't weight this domain heaviest is misallocating study time.
How many questions are on AZ-400 and what is the passing score?+
AZ-400 runs 120 minutes with roughly 40–60 questions, scored on Microsoft's 0–1000 scale where 700 is a pass. The exam costs $165 USD, though pricing can vary slightly by country — confirm the current price on the official Microsoft Learn scheduling page.
How hard is AZ-400 compared to AZ-104 or AZ-305?+
AZ-400 is widely considered one of the harder Expert-level exams because over half the questions live in one dense domain — build and release pipelines — testing multi-stage YAML, deployment-strategy trade-offs, and hybrid pipeline scenarios rather than simple recall. AZ-104 (Associate) tests operating Azure infrastructure; AZ-305 (Expert) tests designing Azure architecture. AZ-400 tests a different axis entirely: designing the delivery process itself, which trips up candidates who are strong at Azure but have never owned a release pipeline end to end.
What changed in the July 27, 2026 AZ-400 update?+
The July 27, 2026 skills update is mostly a terminology refresh — telemetry services now carry their full "Azure Monitor" / "Azure" prefixes (e.g., Azure Monitor Application Insights, Azure VM Insights). The one substantive scope change: the Dependabot bullet under security scanning narrowed to vulnerability detection only — license and version-compliance scanning are no longer part of that specific bullet's scope.
Is AZ-400 worth it in 2026?+
Yes. AZ-400 leads to one of the most recognized Expert-level Microsoft credentials for engineers who own CI/CD pipelines, release engineering, and DevSecOps practice. It signals you can design — not just run — build/release pipeline architecture, deployment patterns, and security scanning strategy across both GitHub and Azure DevOps, which is an increasingly distinct, higher-paid role from general cloud administration.
How is AZ-400 different from GH-900?+
GH-900 (GitHub Foundations) is an entry-level, vendor-neutral overview of core GitHub concepts — repositories, issues, and basic Actions workflows. AZ-400 is an Expert-level exam that assumes that foundation and goes deep on designing enterprise CI/CD architecture, branching strategy, deployment strategy, and DevSecOps practice across both GitHub and Azure DevOps. GH-900 is a reasonable on-ramp for GitHub basics; it is not a substitute for AZ-400 preparation.
Ready to test this against real scenarios?
500 AZ-400 practice questions across all five domains — 40 free, no card required.