Requiring More Than 90 Percent Code Coverage to Merge a Pull Request into Main
You use an Azure Pipelines pipeline to build and test an app named App1. Your company’s development department works in the feature branches. You need to ensure that a pull request will merge into the main branch only when testing covers more than 90 percent of the code. What should you do?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
A code coverage status policy on the main branch blocks the pull request merge until the reported coverage meets the threshold, so configuring branch policy on main is what converts the 90 percent requirement into an enforced gate.
Development happens in feature branches and a pull request may merge into main only when testing covers more than 90 percent of the code. The coverage threshold has to be an enforced condition on the merge rather than something the team is expected to check manually.
Configuring the branch policy on the feature branches, since the merge decision being governed happens on main, so a policy on the feature branches would not gate what is about to land. Publishing test results or creating a coverage configuration file produces the data but enforces nothing on its own.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement is conditional on the merge into the main branch, so the enforcement point must be the main branch. A code coverage status policy configured as a branch policy on main evaluates the coverage associated with the pull request and blocks the merge when it falls below the threshold, which is what makes the more-than-90-percent condition binding rather than advisory. The other requirement, that development happens in feature branches, explains why the feature branches are not where the policy belongs: it is the merge into main that the question governs. The vote was unanimous at 100 for B. schwagalla linked the specific documentation section on protecting a branch using a code coverage policy, which is exactly this mechanism, and Emil_Topics identified it as the branch or status policy.Why the Other Options Are Wrong
Creating a Publish Test Results task (C) publishes the results of tests to the pipeline, which is how the coverage data becomes available, but publishing data enforces no threshold on its own, so a merge could still proceed on a failing coverage number. Creating a code coverage configuration YAML file (D) likewise produces or configures how coverage is gathered and reported, but without a policy consuming that number there is nothing that blocks the merge. Configuring a branch policy for the feature branches (A) is the most tempting distractor because the question mentions feature branches, but a policy there governs merging into the feature branch rather than into main, and the requirement is specifically about the merge into main.Community Comment Notes
The community was unanimous at 100 for B, and the two substance comments both name the mechanism. schwagalla supplied the decisive evidence with a link to the Microsoft Learn section on protecting a branch using a code coverage policy, and Emil_Topics characterized the answer as a branch or status policy. The distractor structure is instructive, because options C and D are the two things you must build before you can have a coverage policy at all, and option A is the branch that appears in the stem but is the wrong enforcement point. Recognizing that the data-producing steps are not the enforcing step is the distinction this question tests.Official Reference
Related Analysis
Practice All AZ-400 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-400 Practice Test →