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.

• ✗

  Use a classic release pipeline instead of YAML for the deployment stages.

  Why it's wrong here

  Using a classic release pipeline for deployment stages is an anti-pattern because it splits your pipeline definition between YAML (build) and a UI-driven editor (release), resulting in two places to configure and enforce policies, and preventing you from capturing the entire delivery process as code. Classic release pipelines store configuration in the Azure DevOps UI, not in the repository, which breaks infrastructure-as-code principles, makes pull-request validation for release logic impossible, and hampers reproducibility across environments. Azure Pipelines now treats YAML as the first-class option for multi-stage CI/CD, and classic releases are only recommended for legacy scenarios where you cannot migrate to YAML.

• ✓

  Publish build artifacts and use them in the release stages.

  Why this is correct

  Publishing build artifacts is essential because it decouples the build phase from the release phase, producing an immutable, versioned binary that can be downloaded by any downstream stage or release pipeline. The Publish Pipeline Artifact task stores files in Azure Pipelines and associates them with the run, so the exact bits that passed tests are the ones deployed, eliminating drift between environments and supporting reliable rollback because each deployment can reference a known artifact version. Without this, release stages would have to rebuild or restore packages, breaking reproducibility and atomic deployment.

• ✗

  Store deployment credentials directly in the YAML file.

  Why it's wrong here

  Storing deployment credentials directly in the YAML file exposes secrets in source control and pipeline logs, violating security best practices. Instead, use Azure Key Vault-backed variable groups or secret variables to securely inject credentials at runtime without hardcoding them.

• ✓

  Use a multi-stage YAML pipeline that includes build, test, and deploy stages.

  Why this is correct

  Implementing a multi-stage YAML pipeline is the recommended approach because it defines build, test, and deploy stages in a single source-controlled file that can be versioned, reviewed, and branched alongside your application code. It supports environment targets, approvals, checks, and stage dependencies natively, allowing you to gate promotions and use conditionals like `condition: succeeded()` to run deployments only after tests pass. YAML also enables you to reuse templates for stage logic, making the pipeline portable across projects and fully auditable as part of the codebase, unlike UI-only classic definitions.

• ✗

  Create a separate pipeline for each microservice.

  Why it's wrong here

  Creating a dedicated pipeline per microservice fragments CI/CD logic, forcing duplicated YAML or classic definitions across repositories and making it exponentially harder to introduce global changes such as updating a build agent image or adding a security scan step. It also prevents you from using a single pipeline with a matrix strategy to iterate over multiple services in parallel, which reduces maintenance and ensures the same build, test, and deployment logic is applied consistently to every microservice. Consolidating into one pipeline with parametrized stage templates keeps the codebase DRY and centralizes approval gates and release orchestration.

Go deeper

Related to this question