Why Build.SourceBranch Doesn't Work Inside a Template Expression
You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?
⚠ Common exam trap
A common mix-up: candidates assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.
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
✓
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
Why this is correct
This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.
- ✗
condition: eq(variables['Build.SourceBranch'], 'main')
Why it's wrong here
This condition is incorrect because Build.SourceBranch always contains the complete refs/heads/ prefix (e.g., 'refs/heads/main'), so comparing directly to 'main' will never be true, causing the condition to fail and the task to run for no branch.
- ✗
condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))
Why it's wrong here
This condition is incorrect because System.PullRequest.TargetBranch only has a value during pull request builds and, even then, it checks the target branch rather than the source branch; using it here would not limit the build to only the main branch for regular CI builds, and it also introduces an unnecessary succeeds() check.
- ✗
condition: ne(variables['Build.Reason'], 'PullRequest')
Why it's wrong here
This condition is incorrect because it merely excludes pull request builds but still allows the task to run for any branch in a non-PR build (e.g., feature branches, develop), so it does not specifically restrict execution to the main branch as required.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-400 exam frequently reuses these exact scenarios with slightly different constraints.
✓condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')Correct answer▾
Why this is correct
This condition is correct because the Build.SourceBranch variable returns the full ref path, such as 'refs/heads/main', so the equality check accurately triggers only when the build originates from the main branch, ignoring other branches or tags.
✗condition: eq(variables['Build.SourceBranch'], 'main')Wrong answer — click to see why▾
Why this is wrong here
Missing 'refs/heads/' prefix, so it won't match.
✗condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))Wrong answer — click to see why▾
Why this is wrong here
This checks PR target branch, not the source branch.
✗condition: ne(variables['Build.Reason'], 'PullRequest')Wrong answer — click to see why▾
Why this is wrong here
This excludes PRs but does not limit to main branch.
Analysis generated from the official AZ-400blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Implementing a Build Pipeline
Key term
Branch
A branch is a pointer to a specific commit in a version control system that allows you to work on features or fixes in isolation from the main codebase.
Key term
Build pipeline
A build pipeline is an automated sequence of steps that compiles source code into a deployable artifact, running tests and checks along the way.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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
4 more ways 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. Which two of the following are valid strategies to implement conditional deployment in a YAML pipeline? (Choose 2)
medium- ✓ A.Use the 'condition' property on a stage
- ✓ B.Use template expressions with parameters
- C.Configure stage filters in the triggers section
- D.Use dependency conditions like 'succeededOrFailed'
- E.Add a PowerShell script to check environment
Why A: Both 'condition' property and template expressions with parameters are valid strategies for conditional deployment in YAML pipelines. The 'condition' property (e.g., `eq(variables['Build.SourceBranch'], 'refs/heads/main')`) controls at runtime whether a stage, job, or step runs, based on variables or expressions. Template expressions with parameters (e.g., `${{ if eq(parameters['environment'], 'prod') }}`) allow you to conditionally include or exclude parts of the pipeline at compile time, making them a powerful tool for conditional deployment based on parameters.
Variation 2. Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?
easy- A.condition: variables['Build.SourceBranch'] == 'main'
- B.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
- ✓ C.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
- D.condition: eq(variables['Build.SourceBranch'], 'main')
Why C: The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.
Variation 3. Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?
easy- A.startsWith(variables['Build.SourceBranch'], 'main')
- B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')
- ✓ C.eq(variables['Build.SourceBranch'], 'refs/heads/main')
- D.eq(variables['Build.SourceBranch'], 'main')
Why C: The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref path (e.g., `refs/heads/main`). The `condition` property evaluates expressions at runtime, and using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` precisely matches the full ref for the main branch, ensuring the stage runs only when the trigger originates from that branch.
Variation 4. Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?
easy- A.condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
- B.condition: contains(variables['Build.SourceBranch'], 'main')
- C.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
- ✓ D.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
Why D: The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.
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.