Expert-level certification covering DevOps process design, source control, build and release pipelines, security and compliance, and instrumentation across Azure DevOps and GitHub, with a worked explanation on every practice question.
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 Processes and Communicationsmedium
A small product team wants a lightweight branching model where every change starts from a short-lived branch off main, is reviewed and validated through a pull request, and is deployed to production immediately after merge, with main always remaining deployable. Which branching strategy matches these characteristics?
- A"Gitflow", in which work flows through long-lived develop and release branches with separate hotfix branches before changes reach a protected main branch.
- B"GitHub Flow", in which short-lived branches are cut from main, merged through a reviewed pull request, and released straight to production while main stays deployable.check_circle Correct
- CTrunk-based development with release trains, in which developers commit directly to the trunk many times a day and changes ship only on a fixed periodic schedule.
- DA fork-and-pull model, in which each contributor works in a personal fork of the repository and the maintainer pulls vetted changes from those external forks into main.
Identify GitHub Flow as the lightweight model of short-lived branches off a deployable main merged via pull request and released on merge. GitHub Flow keeps a single main branch that is always deployable. Each change lives on a short-lived branch, is opened as a pull request for review and automated checks, then is merged and deployed. The absence of long-lived develop or release branches is what distinguishes it from Gitflow and makes it the match here.
Why A is wrong: Gitflow adds long-lived develop and release branches and a heavier ceremony, so it conflicts with the lightweight deploy-on-merge model the team wants.
Why B is correct: GitHub Flow is defined by short-lived feature branches off a single deployable main and release on merge, which is precisely the workflow the team describes.
Why C is wrong: Trunk-based development favours direct commits to the trunk and often scheduled release trains, which does not centre on per-change branches deployed immediately after merge.
Why D is wrong: Forking suits external open-source contribution rather than an internal team, and it describes repository topology, not the deploy-on-merge release cadence asked about.
lock_openFree sampleDesign and Implement Processes and Communicationsmedium
An organisation keeps its repositories on "GitHub" but plans and tracks work in "Azure Boards". They want GitHub commits and pull requests to link to Azure Boards work items so the board shows development progress against each story. What is the recommended way to establish this cross-product linking?
- AMirror each GitHub repository into Azure Repos with a scheduled import so the existing Azure Repos work item linking parses the imported commits and updates the board.
- BAdd a personal access token as a pipeline secret and run a scheduled script that reads the GitHub commit feed and posts updates onto matching Azure Boards work items.
- CInstall the "Azure Boards" app for GitHub, connect the repositories to the project, and reference work items in commits and pull requests using the "AB#" mention syntax.check_circle Correct
- DEnable GitHub Advanced Security on the repositories so its code scanning results are forwarded to Azure Boards and attached to the related stories as development links.
Use the Azure Boards app for GitHub with the AB-hash mention syntax to link GitHub commits and pull requests to work items. The Azure Boards app for GitHub establishes a connection between named GitHub repositories and an Azure Boards project. Once connected, an "AB#" mention in a commit message, pull request, or issue is recognised and a development link is written to the referenced work item, so the board reflects GitHub activity without migrating the source.
Why A is wrong: Mirroring duplicates the source of truth and adds sync overhead, and the team wants to keep developing on GitHub rather than migrate the repositories into Azure Repos.
Why B is wrong: A bespoke script with a long-lived token is fragile and adds operational burden when a supported integration already performs the linking natively.
Why C is correct: The Azure Boards app connects GitHub repositories to a board, and the AB-hash mention in commits and pull requests creates the supported development link on each work item.
Why D is wrong: GitHub Advanced Security scans code for vulnerabilities and secrets and does not create work item links, so it solves a different problem than cross-product traceability.
Frequently asked questions
- How many questions are on the AZ-400 exam?
- The Designing and Implementing Microsoft DevOps Solutions (AZ-400) (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.
- 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.
