Examworthyexamworthy.comDesigning and Implementing Microsoft DevOps Solutions (AZ-400) cheat sheet
Microsoft
Free to share. Examworthy is not affiliated with or endorsed by Microsoft; AZ-400 and related marks belong to their respective owners.
At a glance
Format: Multiple choice, multiple response, and case studies, at a Pearson VUE testing center or online proctored
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
AZ-400 is a requirement-to-capability exam across "Azure DevOps" and "GitHub": almost every question states a constraint such as least downtime, least operational overhead, gradual exposure, least privilege, or no long-lived secrets, and the right answer is the feature built for that constraint, not the most powerful one.
Spot the trap
Tempting wrong answers, and why they failCommon misconception
That a tilde range such as ~1.4.2 admits new minor releases like 1.5.0. It only floats patch updates; a caret range floats across minor releases too.
Design and Implement Build and Release Pipelines
Common misconception
That pasting a commit URL into a work item's comments creates a tracked development link. It only adds a comment hyperlink; hash syntax in the commit or pull request is what forms the real link.
Design and Implement Processes and Communications
Common misconception
That a long feature branch is fine under trunk-based development as long as it merges eventually. Frequent merging to main is the actual requirement.
Design and Implement a Source Control Strategy
Common misconception
That putting a secret in Key Vault satisfies a no-stored-credential requirement. It only relocates the credential; workload identity federation removes it entirely.
Develop a Security and Compliance Plan
Common misconception
That VM Insights covers AKS because nodes are virtual machines. It is not Kubernetes aware and misses pod and container metrics.
Implement an Instrumentation Strategy
Common misconception
That deleting a defective package version outright is the safe cleanup. It erases audit history and can break consumers with no cached copy; unlisting is safer.
Design and Implement Build and Release Pipelines
Common misconception
That lead time is the interval from first commit to production. Lead time starts at request creation, not first commit; the first-commit-to-production span is cycle time.
Design and Implement Processes and Communications
Common misconception
That GitHub branch protection rules can be applied to an Azure Repos branch. Azure Repos enforces merge gates through its own branch policies instead.
Design and Implement a Source Control Strategy
Key terms
Exam-day rules
- Name the requirement in the stem before judging the options. AZ-400 questions state a constraint (least downtime, gradual exposure, least operational overhead, no long-lived secret, end-to-end traceability) and the answer is the capability built for it, not the most powerful one.
- Keep the build and release domain green above all. It is over half the exam, so master YAML mechanics, package feeds, deployment strategies, infrastructure as code, and agent design first; weak marks there cost more than anywhere else.
- Match the platform vocabulary to the named platform. "Azure Repos" uses branch policies, "GitHub" uses branch protection rules; "Azure Artifacts" and "GitHub Packages" are the two package homes; "GitHub Advanced Security" and "Microsoft Defender for Cloud" cover different scanning scopes. Read which platform the stem names.
- When the requirement is no long-lived secret, choose workload identity federation. A service principal client secret, even one stored in "Azure Key Vault", is still an exportable credential, so it loses to a federated OpenID Connect exchange with no stored secret.
- Map deployment requirements straight to a strategy. Deployment slots and swap for near-zero downtime, canary or ring for gradual exposure, blue-green for instant rollback; the named outcome picks the pattern.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the requirement-to-capability maps
- Weeks 1 to 3Go deep on Build and Release Pipelines, part one
- Weeks 3 to 4Finish Build and Release Pipelines, part two
- Week 4Lock Source Control and Processes and Communications