Expert-level certification covering DevOps process design, source control, build and release pipelines, security and compliance, and instrumentation across Azure DevOps and GitHub.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
A team hosts source in "Azure Repos" and tracks work in "Azure Boards". They want every commit and pull request that implements a user story to appear automatically on that story's work item, giving end-to-end traceability from requirement to code. What should a developer include so the link is created without anyone editing the work item by hand?
- AReference the work item by its identifier with the hash syntax, for example "Fixes #142", in the commit message or pull request description so the link is created on save.check_circle Correct
- BAdd the work item title as a tag on the pull request so the boards service can match the wording and attach the commit to the matching story automatically.
- COpen the work item and paste the commit URL into its Discussion field so reviewers can follow the hyperlink back to the implementing change in the repository.
- DAssign the work item to the same person who authored the commit so the boards service infers the relationship and records the change under that story by ownership.
Link commits and pull requests to Azure Boards work items by referencing the item identifier with hash syntax in the message. Azure Repos scans commit messages and pull request descriptions for work item references written with the hash syntax. When it finds one, it adds a development link from that commit or pull request to the named work item, so traceability from requirement to source builds itself as developers work rather than needing manual edits.
Why A is correct: Azure Repos parses the hash-prefixed work item identifier in commit messages and pull requests and writes a development link onto that item, giving automatic source traceability.
Why B is wrong: Matching on free-text titles is unreliable and is not how the boards link is formed, so a tag would not create the development link on the work item.
Why C is wrong: Pasting a URL is a manual edit that produces only a comment hyperlink, not a tracked development link, and the requirement is explicitly to avoid editing the item by hand.
Why D is wrong: Assignment records who owns the item, not which commit implements it, so shared ownership cannot establish a commit-to-requirement link on its own.
lock_openFree sampleDesign and Implement a Source Control Strategymedium
A team of twelve engineers integrates code many times a day and wants to keep merge conflicts and integration debt to a minimum by avoiding long-lived branches. They rely on a continuous integration build that runs on every commit to validate the shared line. Which branching strategy best matches this way of working?
- ATrunk-based development, where everyone commits small changes to a single shared branch frequently and short-lived branches are merged back within hours rather than days.check_circle Correct
- BA release branch model, where each version gets a dedicated long-lived branch that stabilises independently of the main line before any code is shipped to customers.
- CA forking workflow, where each engineer maintains a personal server-side fork and contributes changes back to the central repository only through pull requests across forks.
- DGitFlow, where parallel develop and feature branches accumulate work that is periodically promoted through release and hotfix branches before reaching the main branch.
Match a high-frequency integrating team to trunk-based development to minimise merge conflicts and integration debt. Trunk-based development has all developers commit to a single shared trunk with short-lived branches merged within hours, so changes integrate continuously and conflicts stay small. Models that rely on long-lived parallel branches let divergence accumulate, which is exactly what a team integrating many times a day is trying to prevent.
Why A is correct: Trunk-based development keeps everyone integrating to one shared line with very short-lived branches, which directly minimises merge conflicts and integration debt for a team committing many times a day.
Why B is wrong: Release branches suit stabilising a specific version in parallel with ongoing work, but their long-lived nature is the opposite of the frequent small integrations the team wants, so it does not fit.
Why C is wrong: Forking workflows suit untrusted external contributors to open projects, but for a co-located trusted team they add cross-fork overhead and slow the frequent shared integration that is required here.
Why D is wrong: GitFlow is tempting because it is a well-known model, but its develop and feature branches encourage longer-lived divergence, increasing the integration debt the team is explicitly trying to avoid.
lock_openFree sampleDesign and Implement Build and Release Pipelinesmedium
A .NET team consumes packages from the public NuGet gallery, but a recent outage of that gallery broke their builds, and they also want every external package version that the build ever restored to remain available even if it is later unlisted upstream. Within "Azure Artifacts", which feed capability should they configure to meet both needs?
- AAdd the public NuGet gallery as a separate service connection and point each build's restore step at that connection instead of at the Azure Artifacts feed, so restores skip the feed entirely.
- BConfigure the public NuGet gallery as an upstream source on the feed, so the feed proxies and caches each requested package version and continues serving the saved copy when the upstream is unavailable.check_circle Correct
- CCreate a release view on the feed named for the public gallery and promote external packages into that view manually after each build, so a curated copy of every external version is retained.
- DEnable retention policies on the feed with a high keep count, so the feed automatically downloads the public gallery and preserves a copy of each external package version for builds.
Use an upstream source on an Azure Artifacts feed to proxy and cache a public registry so builds survive outages and retain pulled versions. An upstream source turns the Azure Artifacts feed into a transparent caching proxy in front of a public registry. The first request for a version pulls it from upstream and saves it into the feed; later requests are served from the feed copy, which keeps builds working during an upstream outage and preserves versions even after they are unlisted at the source.
Why A is wrong: Pointing restores straight at the public gallery is tempting because it keeps the existing source, but it leaves the build directly dependent on gallery uptime and saves no copy locally, so neither requirement is met.
Why B is correct: An upstream source makes the feed a caching proxy that saves every restored version into the feed, which both insulates builds from upstream outages and retains versions even after they are unlisted upstream.
Why C is wrong: Views filter and label packages that already live in the feed, and manual promotion of every external version is unworkable, so a view cannot proxy the gallery or guarantee automatic retention.
Why D is wrong: Retention policies only decide which already-stored package versions are pruned, so they neither fetch from the public gallery nor proxy it during an outage, leaving the outage requirement unmet.
More free AZ-400 practice questions with worked answersFrequently asked questions
- How many questions are on the AZ-400 exam?
- The Designing and Implementing Microsoft DevOps Solutions (AZ-400) exam has Typically 40 to 60 questions questions and runs for 150 minutes. The format is multiple choice, multiple response, and case studies, at a pearson vue testing center or online proctored.
- What score do I need to pass AZ-400?
- The pass mark is 700 / 1000. Examworthy gives you a per-domain readiness score so you can see which domains are holding you back before you book.
- How much does the AZ-400 exam cost?
- The exam costs 165 USD to sit. Practising on Examworthy is free to start, with a worked explanation on every question.
- Is there a AZ-400 practice exam?
- Yes. Examworthy's exam mode runs a timed AZ-400 practice exam (mock) paced to match the real exam, scored per domain so you can see exactly where you stand against the blueprint. Timed mocks are free with an account.
- How does Examworthy help me prepare for AZ-400?
- Every practice question carries a worked explanation and a per-distractor rationale, mapped to the official blueprint domains. You learn why each answer is right or wrong, not just the letter.
- Is Examworthy affiliated with Microsoft?
- No. Examworthy is not affiliated with or endorsed by Microsoft. Our questions are original, blueprint-aligned practice material; we never reproduce live exam items.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. AZ-400 and related marks belong to their respective owners.
