AZ-400 Practice Question: Design and implement build and release pipelines
You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?
⚠ Common exam trap
Many exam-takers confuse the order of operations, mistakenly thinking swapping before testing (Option C) is acceptable, but this would bypass the validation that slots are designed to provide.
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
✓
Deploy to a staging slot, run tests against the staging slot, then swap to production.
Deploying to a staging slot first allows you to validate the application by running integration tests against the staging slot without impacting production traffic. After successful testing, swapping the staging slot with the production slot ensures zero-downtime deployment, as Azure App Service swaps the underlying virtual directories and configuration settings instantly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Deploy to a staging slot, run tests against the staging slot, then swap to production.
Why this is correct
Deploying to a staging slot allows the new build to run in a production-like environment, where automated and smoke tests validate functionality without affecting live users; the subsequent swap is atomic and fast, switching the production slot to the staged version with zero downtime and preserving the previous deployment for immediate rollback if needed.
- ✗
Deploy to the production slot directly and run tests after deployment.
Why it's wrong here
Directly deploying to the production slot exposes the new code to users before any validation; tests run after deployment mean defects are already live, potentially causing downtime or user-facing errors, and rolling back requires a full redeploy rather than a simple slot swap.
- ✗
Deploy to a staging slot, swap, then run tests.
Why it's wrong here
Because the swap occurs before tests run, the new release is immediately serving production traffic before its correctness is verified; if tests then fail, users have already experienced the issues, and you must introduce another swap or hotfix to recover, violating the principle of validating before go-live.
- ✗
Deploy to a staging slot, run tests, then delete the staging slot.
Why it's wrong here
Deleting the staging slot after tests pass removes the validated deployment, leaving the original production slot unchanged—no swap means the new version is never published, so the release effectively did not happen and the tested artifact is discarded.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
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.
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 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.