AZ-400 Question 13
Select 3Your organization is strengthening bug and quality traceability in Azure DevOps. The product owner wants each bug linked to code changes, tested in the pipeline, and automatically associated with test coverage results. They also need a robust way to identify and prevent regressions. Which three approaches should you adopt to ensure end-to-end traceability for bugs in Azure DevOps?
- A
Configure branch policies that require a linked work item for every pull request before merging
- B
Establish a separate Git repository for each individual bug fix to simplify bug organization
- C
Reference the bug ID in every commit message or pull request related to the fix
- D
Tag bugs as "Resolved" in Azure Boards without linking them to code changes or test results
- E
Use Pipeline Gates or checks that validate code coverage and test results before deployment
Show answer and explanation
Correct answers: A, C, E
Explanation
To achieve end-to-end bug traceability in Azure DevOps, you must link Board items (bugs) to commits and pull requests in Repos and make sure your pipelines validate quality metrics before changes are released. Requiring work items in pull requests, referencing bug IDs in commits, and enforcing coverage checks or gates helps organizations maintain a complete audit trail of when and how a bug was fixed and tested. For more details, consult Microsoft� Azure Boards and Azure Repos documentation on work item linking and branch policies, as well as Azure Pipelines documentation on quality checks.
- A. Correct.
Correct. Requiring a linked work item for every pull request ensures that all code changes are directly associated with a bug item or user story, providing traceability from the bug to the code fix.
- B. Incorrect.
Incorrect. Using separate repositories for each bug fix is overly complex, increases overhead, and does not inherently provide better traceability. You can track changes and enforce policies within a single or appropriately structured repository.
- C. Correct.
Correct. Referencing the bug ID in commit messages or pull requests directly connects the bug item to its code changes, making it easier to track the status and history of the fix within Azure Boards and Repos.
- D. Incorrect.
Incorrect. Merely tagging bugs as "Resolved" without linking them to actual code changes or test results provides no real traceability. It misses the crucial connection between the bug and the code activity.
- E. Correct.
Correct. Using Pipeline Gates or checks (e.g., Release Gates, policy checks) to validate code coverage and test results ensures that the fix meets quality requirements before deployment, completing the traceability loop from reported bug to tested fix.