AZ-400 - Design and Implement Build and Release Pipelines - Section 3.13

Maintain pipelines by monitoring health, optimising for cost, time, and performance, managing retention, and migrating classic pipelines to YAML.

Monitor pipeline health, optimise for cost and execution time by tuning pipeline concurrency and caching, and manage artifact retention policies to control storage consumption. Migrate classic release pipelines to YAML to consolidate pipeline definitions under source control and enable template reuse.

pipeline healthpipeline optimisationpipeline concurrencyartifact retentionclassic to YAML migration

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelinesmedium

An organisation still runs several classic editor-based build and release definitions and wants to migrate them to YAML so the pipeline lives in source control and is reviewed through pull requests. The lead wants a starting point that reproduces the existing classic build steps rather than authoring the YAML entirely from scratch. Which Azure DevOps feature gives them that starting point?

AEnable the YAML preview toggle in the classic release pipeline, which converts each release stage into a deployment job and replaces the classic definition with YAML in place automatically.
BRun the migrate command in the Azure CLI devops extension against the definition, which rewrites the classic build into YAML and deletes the original definition once the new file is committed.
CUse the export to YAML action on the classic build definition, which generates an equivalent YAML pipeline file the team can commit and refine, reproducing the existing steps as a migration starting point. Correct
DImport the classic definition into a task group, then reference that task group from a new YAML pipeline, because a task group is the supported bridge that carries classic steps into YAML unchanged.

Begin a classic-to-YAML migration by exporting a classic build definition to an equivalent YAML file rather than rewriting it manually. The classic build editor includes an export-to-YAML action that produces a YAML pipeline reproducing the definition's tasks. That generated file is the intended migration starting point: the team commits it to source control, then refines it and runs it through pull-request review. There is no automatic in-place release conversion, no CLI rewrite-and-delete command, and task groups are a classic-only construct that YAML pipelines cannot reference.

Why A is wrong: There is no in-place toggle that rewrites a classic release pipeline into YAML automatically, and classic releases in particular have no direct export, so this describes a conversion path that does not exist.

Why B is wrong: The Azure DevOps CLI has no command that rewrites a classic definition into YAML and removes the original, so this invents tooling and a destructive behaviour that the product does not provide.

Why C is correct: Classic build definitions offer an export-to-YAML action that emits an equivalent pipeline file mirroring the configured tasks, giving the team the source-controlled starting point they want instead of writing the YAML by hand.

Why D is wrong: Task groups are a classic-only reuse mechanism and are not consumable from YAML pipelines, so this points at a feature that cannot bridge into YAML and would not reproduce the build as YAML.

See more AZ-400 practice questions, answers explained.

More in this domain

Back to all Design and Implement Build and Release Pipelines objectives, or the AZ-400 cert hub.

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