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

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

Exhibit

Refer to the exhibit.
```json
{
  "variables": {
    "buildConfiguration": "Release",
    "publishEnabled": false
  },
  "stages": [
    {
      "stage": "Build",
      "jobs": [
        {
          "job": "BuildJob",
          "steps": [
            {
              "script": "echo Building..."
            }
          ]
        }
      ]
    },
    {
      "stage": "Publish",
      "dependsOn": "Build",
      "condition": "eq(variables['publishEnabled'], true)",
      "jobs": [
        {
          "job": "PublishJob",
          "steps": [
            {
              "script": "echo Publishing..."
            }
          ]
        }
      ]
    }
  ]
}
```

Refer to the exhibit. This multi-stage YAML pipeline has a variable 'publishEnabled' set to false. The team wants the Publish stage to run only when 'publishEnabled' is true. However, the Publish stage never runs, even when the variable is changed to true at queue time. What is the most likely cause?

⚠ Common exam trap

Many candidates confuse variable evaluation timing—assuming all variables can be overridden at queue time—when in fact only parameters or explicitly settable variables can be changed, while compile-time variables are baked into the pipeline definition before runtime.

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 'publishEnabled' is not settable at queue time; it is a compile-time variable.

In Azure DevOps YAML pipelines, variables set at the pipeline level (not in a variable group or at queue time) are evaluated at compile time, not at runtime. When 'publishEnabled' is defined as a simple variable in the YAML file, changing it at queue time does not affect the compiled pipeline stages; the condition is evaluated against the compile-time value (false), so the Publish stage never runs. To make it settable at queue time, the variable must be defined as a runtime parameter, or explicitly defined in the pipeline UI with the 'Let users override this value when running this pipeline' checkbox enabled.

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 condition syntax is wrong; it should use 'eq(variables.publishEnabled, true)'.
Why it's wrong here
The condition syntax is not wrong; Azure Pipelines supports expressions like `eq(variables['publishEnabled'], 'true')` and the existing format is valid. Changing it to `eq(variables.publishEnabled, true)` would not affect the real issue, which is the variable being compile-time rather than runtime.
✗
The Publish stage is missing 'dependsOn: Build'.
Why it's wrong here
The claim is incorrect because the Publish stage already defines `dependsOn: Build` in its YAML. The real problem is not a missing dependency but the fact that `publishEnabled` cannot be changed at queue time, so the condition evaluates against the static YAML value.
✓
The variable 'publishEnabled' is not settable at queue time; it is a compile-time variable.
Why this is correct
In Azure DevOps YAML pipelines, variables declared in the `variables` section are compile-time constants; they are evaluated when the pipeline is created and cannot be overridden at queue time unless defined as `runtime` parameters. Therefore, the condition referencing `publishEnabled` will always use the value from the YAML, not any queue-time value, making this the correct diagnosis.
✗
The 'dependsOn' syntax is incorrect; it should be 'dependsOn: Build'.
Why it's wrong here
The `dependsOn` syntax is perfectly valid; `dependsOn: Build` is the standard way to specify a dependency on a previous stage. The issue is unrelated to syntax and lies in the variable's compile-time nature, so this option does not explain the pipeline failure.

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