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 two separate pipelines, one for each platform.

  Why it's wrong here

  Creating two entirely separate pipeline definitions duplicates logic, YAML, and maintenance effort; any change to the build steps must be applied twice and can easily drift out of sync. This approach also forgoes the built-in matrix strategy in Azure Pipelines, which is specifically designed to run identical jobs across multiple agent pools in parallel.

• ✗

  Use a multi-job pipeline with two jobs, each specifying a different pool.

  Why it's wrong here

  While a multi-job pipeline with two jobs each targeting a different pool can build both platforms in parallel, it forces you to duplicate the complete build steps in each job, or at best rely on a shared template to avoid repetition, which adds indirection and maintenance overhead. The job definitions must also hardcode each pool name, and adding a third platform means copying the entire job block again. A matrix strategy, in contrast, defines the steps once and expands a single job into multiple instances, so you get parallel cross-platform builds with drastically less YAML and a single source of truth for build logic.

• ✗

  Use a multi-stage pipeline with a stage for each platform.

  Why it's wrong here

  Multi-stage pipelines execute stages sequentially by default, meaning the Windows stage would not start until the Linux stage fully completes, roughly doubling the build duration. Unlike a matrix strategy, stages also introduce extra planning overhead, and they are better suited for deployment progression with approvals rather than parallel cross-platform compilation.

• ✓

  Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.

  Why this is correct

  Adding a `strategy` with a `matrix` to a job instructs Azure Pipelines to expand that job into multiple job instances at queue time, each with the same steps but with the matrix variables assigned from a specific entry. By mapping a variable like `vmImage` to `['windows-latest', 'ubuntu-latest']` and then referencing it via `$(vmImage)` in the pool specification, the same job runs simultaneously on both Windows and Linux agents, producing a true parallel cross-platform build. This is the idiomatic Azure Pipelines pattern because it keeps the job logic in one place, eliminates duplication, and makes adding or removing a platform as simple as editing a list in the matrix.

Go deeper

Related to this question