The short version
This sheet is for the last review pass, not for learning from scratch. It lists the facts to know, the pairs that get confused, and rules of thumb for scenario questions. It follows the Microsoft study guide titled “Skills measured as of July 27, 2026”. It does not cover everything on the exam, and it contains no real exam questions. Use it to find gaps, then fix them with hands-on work.
Exam facts at a glance
| Item | Detail |
|---|---|
| Exam | AZ-400: Designing and Implementing Microsoft DevOps Solutions |
| Credential | Microsoft Certified: DevOps Engineer Expert |
| Passing score | 700 on a scale of 1 to 1,000 |
| Domain 1 | Processes and communications, 10-15% |
| Domain 2 | Source control strategy, 10-15% |
| Domain 3 | Build and release pipelines, 50-55% |
| Domain 4 | Security and compliance plan, 10-15% |
| Domain 5 | Instrumentation strategy, 5-10% |
| Retakes | 24 hours after the first fail, then 14 days; up to 5 attempts in 12 months |
| Number of questions and time | Not published for this exam; check the time shown when you book |
Domain 1: Processes and communications
- Flow of work. GitHub Flow is lightweight: branch, commit, pull request, review, merge, deploy.
- Traceability. Link work items to commits, pull requests, and builds so you can follow a change from idea to release.
- Metrics. Lead time runs from when an item is created to when it is done. Cycle time runs from when work starts to when it is done. Time to recovery measures how fast you restore service after a failure.
- Collaboration. Wikis use Markdown, and Mermaid draws diagrams from text. Release notes can be generated from Git history.
Pairs.
- A webhook sends events out to another system. A Boards-to-GitHub connection links work items to code.
- Azure Boards tracks work in Azure DevOps. GitHub Projects and Issues do the same job in GitHub.
Decision rule. If the scenario says “measure how long a request waits before anyone starts”, think lead time. If it says “measure how long the team takes once work begins”, think cycle time.
Domain 2: Source control strategy
- Branching. Trunk-based means short-lived branches merged often. Feature branch gives each change its own branch. Release branch isolates a version that needs fixes after cut-off.
- Guardrails. Azure Repos uses branch policies. GitHub uses branch protection rules.
- Large repositories. Git LFS stores large binaries outside normal history. Scalar helps big repositories stay fast.
- Recovery. The reflog finds commits that no branch points to. A revert adds a new commit that undoes an old one.
Pairs.
- Revert keeps history and is safe on shared branches. Reset or rebase rewrites history and is risky on shared branches.
- Tags mark a point in history, such as a release. Branches move.
Decision rule. Sensitive data pushed by mistake? Rotate the secret first, then remove it from history.
Domain 3: Build and release pipelines (the big one)
- Packages. Azure Artifacts and GitHub Packages host feeds. Upstream sources let one feed serve packages from public ones. SemVer is major.minor.patch. CalVer uses dates.
- Testing. Unit tests are fast and isolated. Integration tests check components together. Load tests check behavior under traffic. Quality gates stop a release when a check fails.
- YAML. Know stages, jobs, steps, triggers, parameters, variables, templates, and environments.
- Deployments. Blue-green swaps between two full environments. Canary sends a small share of traffic to the new version. Ring deployment widens exposure in groups. Feature flags change behavior without a deploy.
- Infrastructure as code. Bicep compiles to ARM templates. Azure Deployment Environments offers on-demand environments from templates.
- Maintenance. Watch failure rate, duration, and flaky tests. Set retention and concurrency on purpose. Classic pipelines can be migrated to YAML.
Pairs.
| This | Versus this |
|---|---|
| Microsoft-hosted agent: no maintenance, fresh machine per job | Self-hosted agent: access to private networks, your own tools, you maintain it |
| Variable group: shared plain or secret values | Secure file: a certificate or key file used during a run |
| Pipeline artifact: output passed between jobs or stages | Cache: dependencies reused to speed up later runs |
| `dependsOn` in Azure Pipelines | `needs` in GitHub Actions |
| Environment checks and approvals in Azure Pipelines | Environment protection rules in GitHub |
| Template: reusable YAML | Task group: classic reusable steps |
Decision rules.
- Need to reach resources inside a private network? Think self-hosted agent or runner.
- Need near-zero downtime and an instant rollback? Think blue-green or deployment slots with a swap.
- Need to limit risk to a few users first? Think canary or rings.
- Need the same job on many configurations? Think a matrix.
- Need to cut cost? Look at concurrency, caching, and agent type before anything else.
Domain 4: Security and compliance plan
- Identities. A service principal is an identity you create and manage, with secrets or certificates. A managed identity is tied to an Azure resource, with credentials handled by Azure.
- GitHub tokens. GITHUB_TOKEN is created per workflow run with limited permissions. A GitHub App acts as its own identity. A personal access token acts as a person.
- Secrets. Azure Key Vault stores secrets, keys, and certificates.
- Secretless access. Workload identity federation with OpenID Connect lets a pipeline or workflow sign in to Azure without a stored secret.
- Scanning. Dependency scanning checks packages. Code scanning, such as CodeQL, checks your code. Secret scanning looks for leaked credentials. License checks look at open-source terms.
Decision rules.
- If a secretless option fits, prefer it to a stored secret.
- If the identity should live and die with one Azure resource, think managed identity.
- Give the least privilege that works, and review the default permissions of tokens.
Domain 5: Instrumentation strategy
- Azure Monitor collects metrics and logs. Application Insights watches application performance and supports distributed tracing.
- Log Analytics holds logs queried with KQL.
- Alerts. Metric alerts fire on numbers. Log search alerts fire on query results.
- KQL basics. Start with a table, filter with `where`, pick columns with `project`, count with `summarize`, and order with `sort by`.
Decision rule. Need to react to a number crossing a line? Metric alert. Need to react to a pattern in log text? Log search alert.
Common traps
- The platform changed in the middle of the scenario: Azure Pipelines YAML and GitHub Actions workflows use different keywords.
- Two answers work, and one stated constraint such as cost, isolation, or least privilege decides.
- A stored secret offered next to a secretless option.
- Rewriting shared history when a revert would do.
- Spending the whole time on Domain 3 detail and arriving at Domain 5 with a few minutes left.
- Using Microsoft Learn in the exam for lookups so often that time runs out.
Last-day checklist
- I can explain lead time and cycle time without notes.
- I can name the GitHub and Azure DevOps version of each guardrail.
- I can sketch a multi-stage YAML pipeline with a template and an approval.
- I can pick a deployment strategy from a risk description.
- I can explain why OpenID Connect beats a stored secret.
- I can read a short KQL query.
- I have checked my booking, ID, and equipment using the exam day guide.
- I have slept.
More guides for AZ-400
- AZ-400 Study Plan: 4-Week and 8-Week
- AZ-400 Sample Questions With Answers
- Is AZ-400 Hard? An Honest Difficulty Check
- AZ-400 Prerequisites and Skills Self-Check
- AZ-400 Renewal and Retakes Explained
- Is AZ-400 Worth It? An Honest Look
- AZ-104 vs AZ-400: Which First?
- AZ-305 vs AZ-400: Which Exam First?
Next step
Use this sheet after a timed practice set, then go back to the domains explained page for any area you could not explain. The exam format page covers scoring and retakes. To test yourself, try our AZ-400 practice tests. The full outline is in the AZ-400 overview, and the study guide on Microsoft Learn is the authority.