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

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a variable group and link it to the pipeline.

  Why it's wrong here

  Variable groups are used to manage sets of variables across pipelines, but they do not allow overriding individual variable values at runtime without additional configuration. They are not the best approach for a single manual override.

• ✗

  Edit the template YAML file to hardcode the desired value.

  Why it's wrong here

  Hardcoding a value by editing the template YAML file is fundamentally a compile-time change: it permanently alters the pipeline definition in version control, affecting every future run until the file is reverted. This approach is not dynamic, requires a commit and push (or a PR review) before the pipeline can even be re-run, and eliminates the ability to specify a different value at queue time without another code change. Moreover, because the template may be shared across many pipelines, editing it to force one value creates an unintended global side effect and violates the principle that manual runtime overrides should be applied at the trigger, not baked into the source.

• ✓

  Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.

  Why this is correct

  The pipeline run UI's Variables tab provides a runtime override mechanism specifically designed for this scenario: when you start a manual run, you can expand the 'Variables' section and enter a new value for a YAML-defined variable, and that value is used for that run only without modifying the repository. This works because YAML variables are evaluated at runtime (after the pipeline is triggered), so the override seamlessly replaces the default value defined in the template or pipeline. Crucially, this approach requires zero changes to version-controlled files and leaves the pipeline definition untouched, making it the intended, non-invasive method for ad-hoc manual overrides.

• ✗

  Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.

  Why it's wrong here

  Defining a parameter in the template and passing its value via the 'Override' parameter is incorrect because parameters are compile-time constructs, used to define pipeline structure or resource selection *before* runtime. They cannot directly override a YAML *variable*, which is a runtime value. This option is tempting as parameters *do* allow manual input at queue time, making them suitable for scenarios where users need to specify configuration choices, like target environments or build types, that influence the pipeline's definition before execution begins.

Go deeper

Related to this question