AZ-400 Practice Question: Design and implement build and release pipelines
Your team uses Azure DevOps to manage a monolithic .NET Framework application that is deployed to on-premises Windows servers. You plan to modernize the application by containerizing it and moving it to Azure Kubernetes Service (AKS). The existing build pipeline uses the .NET Framework build task and MSBuild. The release pipeline uses WinRM-based deployment to copy files to on-premises servers. You need to design a new CI/CD pipeline that builds a Docker image, pushes it to Azure Container Registry (ACR), and deploys it to AKS. Your solution should minimize changes to the existing codebase and leverage Azure Pipelines. What should you do?
⚠ Common exam trap
AZ-400 often tests whether candidates reflexively choose 'create a new pipeline from scratch' when the requirement explicitly says to minimize changes — the trap is ignoring the constraint and picking the cleanest-sounding rebuild option.
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
✓
Modify the existing build pipeline by adding a 'Docker' task to build and push the image, and modify the release pipeline to use a 'Kubernetes' task for deployment.
The correct approach is to extend the existing Azure Pipelines definitions rather than rebuild them: add a Docker task to the build pipeline to build and push the image to ACR, and swap the WinRM release step for a Kubernetes task that deploys to AKS. This preserves the existing .NET Framework build logic (MSBuild task) so the codebase and build steps remain largely untouched, satisfying the 'minimize changes' requirement. Azure Pipelines natively supports both the Docker task and the Kubernetes task, so no custom scripting or new pipelines are needed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep the existing build pipeline as is, and add a script to build the Docker image in the release pipeline before deploying.
Why it's wrong here
Building the image in the release pipeline leaves the build pipeline producing MSBuild artefacts, so the image is not versioned or traceable to a commit, and release-time builds bypass CI quality gates. Building images belongs in the build stage. It is tempting because it avoids touching the existing build definition, but that preserves the wrong artefact.
- ✓
Modify the existing build pipeline by adding a 'Docker' task to build and push the image, and modify the release pipeline to use a 'Kubernetes' task for deployment.
Why this is correct
This is the correct approach because it extends the existing CI/CD flow with minimal disruption: add a Docker task to the build pipeline to compile, build, and push the container image to a registry, then replace the release pipeline's deployment step with a Kubernetes task that applies manifests to AKS. This keeps the build artifact (the image) produced during CI and consumes it in CD, which is the recommended practice.
- ✗
Create a new build pipeline from scratch using the 'Docker' template and a new release pipeline with the 'Deploy to Kubernetes' template.
Why it's wrong here
Creating a new build pipeline from scratch using the Docker template and a new release pipeline with the Deploy to Kubernetes template is unnecessary and risky. The existing pipeline can be incrementally extended with a Docker task and a Kubernetes task, avoiding duplication of existing source control triggers, variable groups, and approval gates. Starting from scratch also increases the chance of misconfiguring the new pipeline and loses the history and validation of the current setup.
- ✗
Use self-hosted agents to build the Docker image and deploy to AKS.
Why it's wrong here
Self-hosted agents add infrastructure to maintain and do not themselves build the image, push to ACR or deploy to AKS; Microsoft-hosted agents already run Docker and kubectl tasks. Self-hosted agents are correct when builds need private network access or bespoke on-premises dependencies, not for this migration.
Visual reference
Go deeper
Related to this question
Learn chapter
Managing Build Quality and Package Dependencies
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
Key term
Pipeline
A pipeline is an automated series of steps that takes code from development to production, ensuring quality and speed.
About these practice questions
This AZ-400 question is part of Courseiva's 696-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.