AZ-400 - Design and Implement Build and Release Pipelines (53% of the exam) - Section 3.7

Create reusable pipeline elements, including YAML templates, task groups, variables, and variable groups.

Create reusable pipeline elements using YAML templates, task groups, pipeline parameters, and variable groups so that common build and deployment logic is defined once and referenced across multiple pipelines. Understand the scope and inheritance rules for variables and how template reuse reduces duplication and drift.

YAML templatestask groupsvariable groupspipeline parameterstemplate reuse

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelinesmedium

An organisation is migrating classic editor build and release definitions to YAML pipelines in "Azure DevOps". Several classic definitions rely on task groups to share a sequence of tasks across definitions, and the team must decide how that reuse translates into YAML. Which two statements correctly describe task groups and their YAML equivalent? Select TWO.

  • AA variable group is the YAML equivalent of a task group, because both bundle a named, reusable unit that pipelines reference, so the task sequence is preserved by moving it into a variable group.
  • BA task group can be imported unchanged into a YAML pipeline by referencing its identifier in a resources block, so no rewrite of the shared tasks is needed during migration.
  • CTask groups are a feature of the classic editor only and are not available in YAML pipelines, so a YAML pipeline cannot reference a task group to reuse a sequence of tasks. Correct
  • DA step template referenced with the template keyword is the YAML mechanism that replaces a task group, letting the shared sequence of steps be defined once and included by every pipeline that needs it. Correct
Recognise that task groups are classic-only and that a YAML step template is the equivalent reuse mechanism when migrating to YAML pipelines. Task groups are bound to the classic designer and cannot be referenced from YAML, so reuse that a task group provided is re-created as a YAML step template that pipelines include with the template keyword, while variable groups remain a values-only construct that cannot hold a task sequence.

Why A is wrong: This is tempting because both are shared, named library items, but a variable group only stores values, not tasks, so it cannot carry a sequence of build steps the way a task group did.

Why B is wrong: There is no resources construct that imports a classic task group into YAML; the shared tasks must be re-expressed as a YAML template, so claiming a no-rewrite import is incorrect.

Why C is correct: Task groups exist solely in the classic designer model and have no representation in YAML, so a YAML pipeline cannot consume a task group and the team must use a different reuse mechanism.

Why D is correct: A YAML step template captures a reusable sequence of steps that pipelines include with the template keyword, which is the direct equivalent of the reuse a classic task group provided.

See more AZ-400 practice questions, answers explained.

Exam traps in Design and Implement Build and Release Pipelines

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-400 bank for this domain.

  • Define the shared steps in a variable group and link it to each pipeline, because a variable group centralises values that every consuming pipeline reads at run time without duplicating any logic.

    Why it is wrong: A variable group shares values such as connection strings or settings, not reusable build steps, so it cannot hold the build-and-sign sequence the team needs to factor out and parameterise.

  • A template parameter has no data type, so the template author cannot constrain it to a list of allowed values or reject an out-of-range input before tasks run.

    Why it is wrong: This is tempting because variables are untyped strings, but parameters are typed and support allowed-value lists, so the author can validate input at compile time, making this statement false for parameters.

  • Add the template repository under "extends" at the top of the pipeline, so the whole pipeline inherits from the external file and its repository is resolved on extension.

    Why it is wrong: The extends keyword consumes one template as the pipeline's base, but it still relies on a declared repository resource to locate an external repo, so it does not by itself make the repo available.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.