AZ-400 Practice Question: Design and implement build and release pipelines
You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Each microservice has its own build pipeline that produces a container image. You need a single release pipeline that can deploy multiple microservices in a coordinated manner, but you want to avoid rebuilding the deployment pipeline for each microservice. The deployment should use Helm charts. What should you do?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.
A single release pipeline can consume multiple build artifacts (one per microservice) and use Helm charts to deploy each microservice in stages. This allows coordinated deployment without duplicating the pipeline logic. Option A is incorrect because creating separate release pipelines for each microservice and triggering them sequentially lacks a single orchestration point and can lead to coordination failures. Option B is incorrect because creating a single build pipeline that produces all container images couples the builds and prevents independent microservice development. Option D is incorrect because a single multi-stage YAML pipeline that builds and deploys all microservices together also couples the build and deploy stages, and does not allow each microservice to have its own independent build pipeline.
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 a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.
Why it's wrong here
Separate release pipelines per microservice with pipeline completion triggers create implicit, decentralized orchestration rather than a single auditable deployment plan. This approach makes cross-service ordering, environment approval gates, and coordinated rollbacks difficult to manage, and multiplies the number of pipelines, service connections, variables, and permissions that operators must maintain.
- ✗
Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.
Why it's wrong here
A single build pipeline that produces all container images couples the build lifecycle of every microservice, so any one code change unnecessarily triggers builds and potential deployments for all services. It also yields a single monolithic deployable artifact, erasing per-microservice versioning and granular release, which increases the blast radius and defeats the independent scaling and deployment benefits of a microservices architecture.
- ✓
Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.
Why this is correct
A single release pipeline consuming multiple build artifacts, one per microservice, preserves independent artifact versioning while centralizing deployment coordination in one auditable process. Using a Helm chart per microservice allows each service to be templated and configured independently, while shared release stages, approval gates, and rollback steps can orchestrate the full deployment consistently across environments.
- ✗
Create a single multi-stage YAML pipeline that builds and deploys all microservices together.
Why it's wrong here
A single multi-stage YAML pipeline that builds and deploys all microservices together tightly couples build and release phases, preventing build artifacts from being reused or promoted independently across environments. It also complicates applying different approval gates per service and forces a full rebuild of the entire application when only one microservice changes, which undermines modular deployment and increases CI/CD cycle time.
Visual reference
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
YAML pipeline
A YAML pipeline is a text-based file written in YAML format that defines an automated series of steps for building, testing, and deploying software in a continuous integration and continuous delivery (CI/CD) system.
Key term
Release pipeline
A Release pipeline is an automated sequence of steps that takes software from code commit to production deployment, ensuring quality and consistency.
About these practice questions
This AZ-400 question is part of Courseiva's 823-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.