Courseiva
Design and implement build and release pipelineseasyMultiple ChoiceObjective-mapped

Why Build.SourceBranch Doesn't Work Inside a Template Expression

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

Quick Answer

A condition referencing Build.SourceBranch inside a template expression won't evaluate correctly because template expressions run at compile time, before runtime variables like Build.SourceBranch even exist — template expressions can only see parameters and variables defined within the template itself. Branch-based logic like this needs a runtime condition on the job or stage instead.

⚠ Common exam trap

Candidates may assume that all predefined variables are available in template expressions, but runtime variables like Build.SourceBranch are only available at runtime. The correct approach is to use a runtime condition (e.g., in the job's condition field) instead of a template expression for branch-based conditions.

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 variable 'Build.SourceBranch' is not available in the condition context.

The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is used in a template expression, which is evaluated at compile time. However, 'Build.SourceBranch' is a runtime variable that is not available during compile time, causing the condition to fail. Template expressions can only reference parameters or variables defined within the template itself, not runtime pipeline variables. To conditionally run jobs based on the branch, use a runtime condition (e.g., in the 'condition' property of a job or stage) instead of a template expression.

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 variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

    Why it's wrong here

    Incorrect. 'Build.SourceBranch' is a valid predefined variable, though it contains the full ref (e.g., 'refs/heads/main'). The issue is not a misspelling; it's that this variable is unavailable in template expressions (compile time).

  • The condition syntax is correct but the branch name should not include 'refs/heads/'.

    Why it's wrong here

    Incorrect. The branch name in 'Build.SourceBranch' indeed includes 'refs/heads/', but that is not the root cause. The variable itself is valid at runtime; the problem is its availability at compile time.

  • The variable 'Build.SourceBranch' is not available in the condition context.

    Why this is correct

    Correct. Template expressions are evaluated at compile time, where runtime variables like 'Build.SourceBranch' are not available. Therefore, the condition cannot evaluate correctly. Use a runtime condition instead, or pass the branch as a parameter.

  • The condition should be in a template expression instead of a runtime condition.

    Why it's wrong here

    Incorrect. The condition is already in a template expression; the issue is that it uses a runtime variable. Changing to a runtime condition (outside the template expression) would fix the problem, but the statement 'should be in a template expression' is backwards.

About these practice questions

One of 823 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

5 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. 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 2. 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.

Variation 3. 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 4. 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 5. 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?

easy
  • A.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
  • B.condition: eq(variables['Build.SourceBranch'], 'main')
  • C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))
  • D.condition: ne(variables['Build.Reason'], 'PullRequest')

Why A: 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.

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.