Enforcing a Pre-Deployment Security Status Check on Development Branch Policies for App1

Design and implement branching strategies for the source code
Answer Correct answer: A — A status check on the development branch policies runs the custom security tool in the normal flow of work, so failing App1 code is blocked early.

You use Azure Pipelines pipeline to build and deploy an app named App1. You need to ensure that before App1 is deployed, all the code for the app passes a security validation by using a custom tool. What should you do?

  1. Add a status check to the policies of the branch used by your company's development department. Correct Answer
  2. Add a status check to the policies of the main branch.
  3. Add a service hook to the project.
  4. Limit the job authorization scope to the current project for all the release pipelines.

Community Votes

A
71%
B
29%

71% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

A branch policy status check integrates an external validation with the merge gate, so attaching it to the development branch the team's work actually flows through catches vulnerabilities before code ever reaches the main branch or production.

An Azure Pipelines pipeline builds and deploys an app named App1, and every piece of code must pass a security validation from a custom tool before deployment. The validation has to be enforced through branch policies as a status check so that a failing result blocks the code from progressing.

Adding the status check to the main branch policies instead. That still blocks the main branch, but by then the code has already been approved and merged, so a failure is discovered too late and a rollback becomes necessary rather than a simple fix-forward.

Community Discussion (6 comments)

Dankho 👍 2 Selected: A
you need to catch vulnerabilities "before" deployment because once it's in PROD with vulnerabilities, you would need to do a rollback. So, performing the tests in TEST environment is more appropriate and cause less headaches of having to rollback.
yaguitoEC 👍 1 Selected: B
B is correct, deployment
Zangi 👍 2 Selected: A
A is correct answer. Do not listen MrAZ105
MrAZ105 👍 1 Selected: B
B is correct
UrbanRellik 👍 1 Selected: A
Status check on a PR of the feature branch. Once approved, merge to main. Performing a check on the main branch means that it's already been approved and failed the status check after approval.
MrAZ105 👍 3
I would say option A Option B could work but is less ideal because it's applied to the main branch, and security validation should generally be enforced earlier in the development process (e.g., on the feature/development branches) to catch issues before they reach the main branch.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

The requirement is that all code for App1 passes a security validation before deployment, and the mechanism for gating merges with an external check is a status check in branch policies. Attaching that status check to the branch used by the development department means the custom security tool runs on every push and pull request in the flow of work, and a failure stops the code before it advances toward deployment. This is the fail-fast placement: a vulnerability caught on the development branch is fixed by amending the commit, with no production impact. The vote was 71 for A and 29 for B. MrAZ105 explained the reasoning best, noting that option B could work but is less ideal because the main branch is where code has already been approved, so validation should happen earlier on the feature or development branches.

Why the Other Options Are Wrong

Adding a status check to the main branch policies (B) enforces the validation one step too late. MrAZ105 and UrbanRellik both observed that by the time code is on the main branch it has already been approved, and UrbanRellik added that a failure at that point means the check rejects code that was already merged, which is exactly the wrong order of operations. Dankho made the same point in operational terms, noting that catching vulnerabilities before deployment avoids having to roll back once they are live in production. Adding a service hook to the project (C) only subscribes to events and posts notifications, so it can report a validation result but cannot gate the merge or block a deployment. Limiting the job authorization scope to the current project for release pipelines (D) narrows what a pipeline job is permitted to do, which is a permission change and does not add any validation step at all.

Community Comment Notes

The community favored A at 71 votes, and the highest-liked comment, MrAZ105 with three likes, argued for A specifically on the grounds that security validation should be enforced earlier in the development flow so issues are caught before they reach the main branch. Zangi explicitly warned readers not to follow MrAZ105's advice and confirmed A. Dankho and UrbanRellik independently reinforced the same conclusion from the rollback-avoidance and merge-ordering angles respectively, so the majority reasoning is consistent rather than a bare vote count.

Related Analysis

You use an Azure Pipelines pipeline to build, test, and depl

A-Grade

You plan to deploy a solution that will include multiple mic

A-Grade

You have an Azure subscription. You create two Bicep templat

A-Grade

Practice All AZ-400 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-400 Practice Test →

← Back to AZ-400 Study Guide