AZ-400 Template parameters Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

  Why it's wrong here

  Azure DevOps YAML pipelines do not recognize an 'overrides' keyword anywhere in the schema; there is no built-in mechanism to designate which steps should be replaced from outside a template. Attempting to use it would cause the pipeline to fail at parse time with a 'Validation Error' because the YAML is invalid. The correct way to customize steps is to design the template to accept step definitions as parameters.

• ✗

  Create a copy of the template and modify the step directly.

  Why it's wrong here

  Copying the template and modifying the step in the copy is a manual workaround that defeats the entire purpose of a shared template: you now have two divergent copies to maintain, and any future fixes or enhancements to the original template will not propagate to the copy. This approach violates the DRY principle and creates duplication, which is exactly what templates are meant to eliminate. It also makes the pipeline harder to audit and update, since the effective logic now lives in multiple places.

• ✗

  Use a conditional 'if' statement in the template to skip steps based on a parameter.

  Why it's wrong here

  A conditional `if` statement inside a template can only include or exclude steps that already exist in that template based on parameter values; it does not allow the caller to supply completely new steps or redefine existing ones. The logic remains internal to the template, so you cannot 'swap' a step definition from the calling pipeline. To truly override steps, the template must expose a steps parameter that the caller can inject, rather than relying solely on conditionals.

• ✓

  Use template parameters with a 'steps' object that can be injected to override the step.

  Why this is correct

  This is the supported pattern: declare a template parameter of type 'steps' and pass it through to the steps section of a job or stage. For example, define `parameters: - name: stepsOverride type: steps default: []` and then use `steps: ${{ parameters.stepsOverride }}` in the template; the caller can supply a list of steps as an argument to replace the default behavior. Because the parameter is a full steps object, the calling pipeline can inject any arbitrary step definitions without modifying the template file itself. This approach keeps the template reusable while allowing per-pipeline overrides.

Go deeper

Related to this question