Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

{
  "variables": {
    "buildConfiguration": "Release",
    "majorVersion": 1,
    "minorVersion": 0,
    "revision": $[counter(variables['minorVersion'], 0)]
  },
  "steps": [
    {
      "script": "echo $(Build.BuildNumber)"
    }
  ]
}

Refer to the exhibit. You have a YAML pipeline with the variables shown. What will be the value of $(Build.BuildNumber) on the first run?

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

✓

20250101.1

The pipeline does not define a custom build number format, so Azure DevOps defaults to the date-based format 'yyyyMMdd.revision'. On the first run of the day, the revision starts at 1, resulting in a Build.BuildNumber like '20250101.1'. The counter expression (not shown in the exhibit) is a separate variable and does not affect Build.BuildNumber. Therefore, the correct answer is B.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
1.0.0.0
Why it's wrong here
1.0.0.0 is incorrect because it is not the default Build.BuildNumber format. The default format is a two-part date and revision string (e.g., yyyymmdd.r), not a four-part version. A four-part version would require an explicitly defined custom build number format in the YAML pipeline.
✓
20250101.1
Why this is correct
20250101.1 is correct because Azure Pipelines automatically sets Build.BuildNumber to $(Date:yyyyMMdd).$(Rev:r) when no custom format is specified. On January 1, 2025, the first build of the day gets the revision 1, producing 20250101.1, and each subsequent build increments the revision.
✗
1.0.0
Why it's wrong here
1.0.0 is incorrect because that value would only appear if the pipeline had a custom Build.BuildNumber format like $(majorVersion).$(minorVersion).$(revision), with a counter or revision starting at 0. Since the question refers to the default behavior, the result is the date-based format, not a manually constructed semantic version.
✗
1.0.1
Why it's wrong here
1.0.1 is incorrect because the default Azure DevOps build number format is date-based, not a customized semantic version. If you were using a counter, it would start at 0, so the first build would be 1.0.0, not 1.0.1, and the counter would be scoped to the build definition, not automatically incremented from 1.

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question