Code
AZ-400
Level
Expert
Pass
700/1000
Cost
$165 USD
Questions
~40–60
Duration
120 min
Renewal
Free / annual
Role
DevOps Engineer Expert
Processes & Communications
10–15%Tests whether work, feedback, and documentation flow traceably between GitHub/Azure Boards and the team — not tooling trivia.
| Concept | What it does | Watch for |
|---|---|---|
| GitHub Flow | Lightweight branch model: branch from main, PR back into main. The default "structure for flow of work" the exam expects unless a scenario demands more. | Don't reach for Gitflow when GitHub Flow already satisfies the requirement — added branch types are a distractor. |
| Flow metrics | Cycle time, lead time, and time-to-recovery — the dashboard metrics tied to "flow of work," distinct from raw velocity. | A scenario about "how long from commit to production" wants lead time, not cycle time (which starts at work-in-progress). |
| Webhooks | The generic integration mechanism for pushing events to external systems (Teams, custom tooling) not covered by a native connector. | Native Teams/Azure Boards integrations exist — only reach for a raw webhook when no built-in integration covers the target. |
| Mermaid in wikis | Diagram-as-code syntax supported directly in Azure DevOps/GitHub wikis for process diagrams. | Tested as a specific named capability — know it renders inline without an external tool. |
Source Control Strategy
10–15%Branch strategy and repository scaling — the exam tests picking the strategy that fits a team\'s size and release cadence, not naming every strategy that exists.
| Concept | What it does | Watch for |
|---|---|---|
| Trunk-based | Short-lived feature branches merged frequently into a single main branch; minimal long-lived parallel branches. | The default answer for teams already using short-lived branches + PRs — don't add Gitflow structure they don't need. |
| Release branch | A branch cut for stabilizing a specific release, allowing main to keep moving with new work. | Appears when a scenario needs to patch an already-shipped version without pausing ongoing development. |
| Git LFS | Stores large individual files (binaries, media) as pointers in Git, content elsewhere. | Solves large files, not large repos — don't confuse with Scalar. |
| Scalar | Optimizes clone/checkout performance for very large repositories (many files, deep history, monorepos) regardless of file size. | Solves large repos, not large files — the inverse problem to Git LFS. |
| Branch policies | Enforce required reviewers, required builds, and merge restrictions before a PR can complete. | The mechanism for "prevent merging without a passing build" — not a pipeline setting. |
Build & Release Pipelines
50–55% — biggestMore than half the exam. Package management, testing gates, YAML pipeline design, deployment strategy, IaC, and pipeline maintenance all live here.
| Concept | What it does | Watch for |
|---|---|---|
| SemVer | Semantic versioning (major.minor.patch) — communicates breaking vs. compatible changes to consumers of a package. | Pick SemVer when consumers need to reason about compatibility; CalVer (date-based) when release cadence matters more than compatibility semantics. |
| Feed views | Local vs. release views in Azure Artifacts/GitHub Packages — gate which packages are promoted to consumers after passing quality checks. | The mechanism for "only vetted packages reach consumers" — not a branch policy. |
| Multi-stage YAML | A pipeline defined as ordered stages, each with jobs that can run in parallel — the standard modern pipeline shape. | Classic (UI-based) pipelines are being phased out; migration to YAML is its own tested skill. |
| YAML templates | Reusable pipeline definitions referenced across multiple pipelines — avoids duplicating the same steps everywhere. | Paired with variable groups and task groups for the "reusable pipeline elements" objective. |
| Canary | Routes a small slice of live traffic to a new version to catch regressions before full rollout. | Traffic-percentage based — distinct from ring-based (population-based) and blue-green (instant full swap). |
| Ring-based deployment | Deploys to internal rings first (dogfood, early adopters), then general availability — controls who gets a build, not traffic percentage. | Population-based, not percentage-based — the distinction the exam tests against canary. |
| Blue-green | Two full environments; traffic swaps instantly between them — prioritizes fast, low-risk rollback. | Pick this when the requirement is "rollback must be immediate," not gradual exposure. |
| Feature flags | Azure App Configuration Feature Manager toggles a code path on/off independent of deployment. | Decouples release from deploy — code can ship dark to everyone and still be off for all users. |
| Bicep / desired state config | Declarative IaC defining the target infrastructure state; Azure Automation State Configuration or Machine Configuration enforces it on VMs. | The exam distinguishes "define the state" (Bicep/ARM) from "enforce the state on a running VM" (Machine Configuration). |
▸ decide: a scenario needing an instant full rollback wants blue-green; one needing a small internal group to see it first wants rings; one needing a percentage of live traffic wants canary.
Security & Compliance
10–15%Auth methods, secrets management, and scanning — the exam tests which control applies to which credential or scan target.
| Concept | What it does | Watch for |
|---|---|---|
| Managed identity | Azure-issued identity tied to an Azure resource — no credential to store or rotate at all. | Azure-to-Azure only. For external CI/CD (GitHub Actions) calling into Azure, this is not the answer. |
| Workload identity federation (OIDC) | Short-lived, federated token issued to GitHub Actions/Azure Pipelines instead of a stored secret. | The secretless option when CI/CD is external to Azure — this is what "no long-lived secret" scenarios want. |
| Key Vault | Stores secrets, keys, and certificates referenced by a pipeline at runtime. | Storage/retrieval of a secret that must exist — different problem than eliminating the secret entirely (OIDC). |
| Dependabot alerts | Scans the dependency graph for known vulnerabilities in third-party packages. | As of the July 27, 2026 update, scoped to vulnerability detection only — licensing/version-compliance scanning is no longer part of this bullet. |
| CodeQL | Static analysis on first-party code you wrote, finding vulnerability patterns like injection flaws. | First-party code, not dependencies — the distinction against Dependabot. |
| Defender for Cloud DevOps Security | Unified posture view connecting GitHub and Azure DevOps — exposed secrets, misconfigurations, open-source risk in one place. | The answer when a scenario wants "one view across both platforms," not a single scan type. |
Instrumentation
5–10%Smallest domain — monitoring configuration and reading the telemetry it produces.
| Concept | What it does | Watch for |
|---|---|---|
| Application Insights | Collects application-level telemetry, including distributed tracing across services. | The tool for "trace a request across multiple services" scenarios. |
| Azure Monitor Logs | Central log store queried with KQL — the destination most other Azure Monitor telemetry feeds into. | Know a basic KQL query pattern (filter + project) — the exam expects reading, not writing complex KQL. |
| Pipeline alerts | Configured directly in GitHub Actions/Azure Pipelines for build/release events — separate from Azure Monitor resource alerts. | A scenario about "alert when a pipeline fails" wants the pipeline's own alerting, not an Azure Monitor resource alert. |
Try 40 Free AZ-400 Practice Questions
Scenario-based, calibrated to the same design-decision difficulty as the real exam. No card required.
Start Free Practice →Acronyms
| LFS | Git Large File Storage |
| SemVer | Semantic Versioning |
| CalVer | Calendar Versioning |
| IaC | Infrastructure as Code |
| OIDC | OpenID Connect |
| KQL | Kusto Query Language |
| ARM | Azure Resource Manager |
| PAT | Personal Access Token |
Exam-day checklist
- ☐ Re-read the “decide” callout under Domain 3 — canary vs. ring vs. blue-green is the single highest-yield distinction on the exam.
- ☐ Confirm you can explain managed identity vs. workload identity federation (OIDC) vs. a bare service principal secret, out loud, in one sentence each.
- ☐ Skim the acronym table once — recognizing OIDC, KQL, and IaC by sight saves reading time on scenario questions that assume you already know them.
- ☐ Do not cram new material the night before. AZ-400 rewards calm trade-off reasoning over freshly memorized facts.
FAQ
Is this cheat sheet enough to pass AZ-400 on its own?
No. AZ-400 is heavily scenario-based and assumes hands-on experience building real pipelines. Use this as a final-review consolidation, paired with hands-on time in Azure DevOps or GitHub Actions and full-length practice questions — not as a substitute for either.
What is the single biggest domain to prioritize?
Design and implement build and release pipelines, at 50–55% — more than the other four domains combined. It covers package management, pipeline testing, YAML authoring, deployment strategy, infrastructure as code, and pipeline maintenance.
What is the passing score and cost for AZ-400?
The passing score is 700 out of 1000. The exam costs $165 USD, runs 120 minutes, and has roughly 40–60 questions.
What are the prerequisites for AZ-400?
No prerequisite is enforced at registration, but the DevOps Engineer Expert certification requires an active Azure Administrator Associate (AZ-104) or Azure Developer Associate certification alongside passing AZ-400.
Is this cheat sheet current with the latest AZ-400 exam objectives?
Yes. It is built directly from Microsoft's official AZ-400 skills-measured outline, current as of the July 27, 2026 update — the same source used in our full AZ-400 study guide, so the domain weights and terminology here match what Microsoft Learn currently publishes.
How does a cheat sheet differ from the full AZ-400 study guide?
The study guide walks through each domain in depth with a week-by-week plan for building the underlying skills. This cheat sheet assumes you've already studied and exists for rapid final review the week of your exam — short definitions and the specific trade-offs that decide close-call questions, not step-by-step instructions.
What should I review last, the night before the exam?
The "watch for" column in each table below. It captures the control-vs-control distinctions (which deployment pattern, which auth method, which scan type) that repeatedly separate correct answers from plausible-looking wrong ones — a higher-yield use of your last hour than re-reading full documentation.