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.

• ✗

  Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.

  Why it's wrong here

  Azure DevOps provides no direct JSON export/import for pipelines that reliably captures all dependencies such as service connections, agent pools, variables, triggers, and permissions. Even if you script a REST API-based export, classic build/release definitions often use linked resources and custom task extensions that break when reimported, so skipping validation would propagate broken references into production. This approach also lacks the incremental validation that a proper migration tool gives, making it high-risk for minimal time savings.

• ✗

  Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.

  Why it's wrong here

  Manual recreation is inherently error-prone and time-consuming because pipelines often contain dozens of configuration fields, environment-specific variables, and integration points with service endpoints and agent queues. Even for the 20 critical pipelines, hand-building them in Azure DevOps Services invites human mistakes and inconsistencies, and doing the rest manually multiplies the effort and risk of silent deviations. This approach does not offer automated validation, rollback, or a repeatable process, contradicting the goal of minimizing downtime in a structured migration.

• ✓

  Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.

  Why this is correct

  The Azure DevOps Migration Tools (the community-supported VSTS/Azure DevOps Migration Tools) are specifically designed to programmatically migrate build and release pipelines, service endpoints, and certain metadata between Azure DevOps organizations, allowing you to run trials against a test organization first. By replicating test pipelines first, you can validate variable resolution, service connection authentication, agent pool references, and task extension compatibility; fixing issues early prevents them from appearing later. Afterward, migrating the remaining pipelines in batches gives you controlled rollout, checkpointing, and the ability to fix issues before going live, which matches the requirement for minimal downtime and reduced risk.

• ✗

  Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.

  Why it's wrong here

  An in-place upgrade of Azure DevOps Server only updates the on-premises server version; it does not move anything to the cloud, and there is no path to directly 'upgrade Server to Services.' The Azure DevOps Data Migration Tool is intended for a full collection-level migration of the entire server database (including work items, source code, and all pipelines) to an Azure DevOps Services organization, which is a heavy, one-time, all-or-nothing process rather than a selective pipeline migration. This option is therefore disproportionate for a pipeline-only migration and still does not provide the incremental validation needed to safely bring only 20 critical pipelines first.

Go deeper

Related to this question