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 failTempting but wrong
Pointing build restores directly at the public NuGet gallery via a service connection protects builds from gallery outages.
Why it fails
Restoring straight from the public gallery keeps the build wholly dependent on gallery uptime and saves no local copy. An outage still breaks the build, and unlisted versions are lost. An Azure Artifacts upstream source is needed to proxy and cache versions locally.
Design and Implement Build and Release Pipelines
Tempting but wrong
Adding the work item title as a tag on a pull request lets Azure Boards match the wording and attach the commit to the right story.
Why it fails
Matching on free-text titles is unreliable and is not how Azure Boards forms a development link. A tag creates no link to the work item. The supported mechanism is a hash-prefixed work item identifier in the commit message or pull request description.
Design and Implement Processes and Communications
Tempting but wrong
A release branch model is the best fit for a team that integrates code many times a day.
Why it fails
No. A release branch model gives each version a dedicated long-lived branch that stabilises independently. That long-lived divergence is the opposite of frequent small integrations, so it suits stabilising a shipping version rather than high-frequency integration. Trunk-based development fits that need.
Design and Implement a Source Control Strategy
Tempting but wrong
Storing a service principal client secret in Azure Key Vault and reading it at run time satisfies a no-stored-credential requirement.
Why it fails
Putting the secret in a vault improves storage hygiene but the client secret is still a long-lived credential that can be exported or leaked. A no-stored-credential requirement is met only by removing the credential, for example with workload identity federation, not by relocating it.
Develop a Security and Compliance Plan
Tempting but wrong
VM Insights can capture a web API's per-request rates, traces, and downstream dependency calls.
Why it fails
VM Insights gathers guest operating system performance counters and a host dependency map for virtual machines. It works at the infrastructure level and never sees application request rates, distributed traces, or dependency calls inside the API. For that, use Application Insights.
Implement an Instrumentation Strategy
Tempting but wrong
A release view that you manually promote external packages into can cache a public registry and guarantee version retention.
Why it fails
Views only filter and label packages that already exist in the feed; they cannot proxy an external registry. Manually promoting every external version is unworkable. Caching and automatic retention from a public registry come from an upstream source, not a view.
Design and Implement Build and Release Pipelines
Tempting but wrong
Pasting a commit URL into a work item's Discussion field creates a tracked development link from the item to the implementing change.
Why it fails
Pasting a URL is a manual edit that produces only a comment hyperlink, not a tracked development link. It also fails any requirement to avoid editing the item by hand. A hash reference in the commit or pull request is what produces a real development link.
Design and Implement Processes and Communications
Tempting but wrong
A forking workflow is ideal for a co-located, trusted team that wants frequent shared integration.
Why it fails
No. Forking workflows suit untrusted external contributors to open projects, where each person works on a personal fork and contributes via cross-fork pull requests. For a trusted internal team this adds cross-fork overhead and slows the frequent shared integration that trunk-based development provides.
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