Why a Non-Main-Branch Release Still Got Approved and Deployed
Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?
Quick Answer
A feature-branch release getting approved and deployed despite a main-only policy almost always means the pre-deployment condition never had a branch filter applied to the artifact trigger — without one, any release regardless of source branch can sail through the approval gate, since the approval step itself doesn't check which branch the artifact came from.
⚠ Common exam trap
Test-takers frequently assume that requiring approval alone is sufficient to control which branches are deployed, but Azure DevOps separates branch filtering from the approval gate, so without an explicit artifact branch filter, any branch can be approved and deployed.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The pre-deployment condition did not include a branch filter on the artifact.
The pre-deployment condition in Azure DevOps release pipelines can include a branch filter on the artifact to restrict which branches trigger a release. If this filter is not configured, any release—regardless of the source branch—can proceed through the approval gate. Since the feature branch release was approved and deployed, the most likely cause is that the pre-deployment condition lacked a branch filter to enforce that only artifacts from the main branch are eligible.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The deployment queue settings were set to 'Deploy all in parallel'.
Why it's wrong here
Deployment queue settings control parallel execution, not branch filtering.
- ✓
The pre-deployment condition did not include a branch filter on the artifact.
Why this is correct
Branch filters must be configured on the artifact trigger or pre-deployment condition to restrict branches.
- ✗
The artifact was published from a build pipeline that allowed any branch.
Why it's wrong here
Even if the build pipeline allows any branch, the release pipeline can still filter.
- ✗
The pre-deployment condition was set to 'After release' instead of 'Before deployment'.
Why it's wrong here
The timing of the condition does not restrict which branch a release originates from.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
Key term
Release pipeline
A Release pipeline is an automated sequence of steps that takes software from code commit to production deployment, ensuring quality and consistency.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You need to ensure that only specific branches can trigger a release to production in Azure Pipelines. What should you configure?
easy- A.Add an approval gate that requires a manager to approve the release.
- B.Add a deployment gate that checks the source branch.
- ✓ C.Add a branch filter to the release pipeline's artifact trigger.
- D.Add a branch filter to the build pipeline trigger.
Why C: A branch filter on the release pipeline's artifact trigger allows you to specify which branches of the source artifact (e.g., a build pipeline) should automatically trigger a release. By configuring this filter to only include branches like 'main' or 'release/*', you ensure that only builds from those specific branches can initiate a release to production, providing precise control over deployment triggers.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.