AZ-400 Practice Question: Design and implement build and release pipelines
During a release pipeline, you notice that the deployment to staging fails intermittently due to a timeout waiting for the health check endpoint to return 200. The health check typically passes within 30 seconds, but occasionally takes up to 2 minutes. You need to make the deployment more reliable without affecting the overall release time. What should you do?
⚠ Common exam trap
Test-takers frequently choose retry logic (Option B) thinking it handles intermittent failures, but retries increase total release time, whereas simply increasing the timeout (Option C) waits once for the expected duration without extra cycles.
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
✓
Increase the health check timeout in the pipeline task to 3 minutes.
Increasing the health check timeout to 3 minutes accommodates the occasional 2-minute delay without failing the deployment. Since the health check typically passes within 30 seconds but can take up to 2 minutes, a 3-minute timeout ensures the pipeline waits long enough for the endpoint to return HTTP 200, making the deployment more reliable without adding extra retry cycles or changing the overall release time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the health check from the pipeline and rely on monitoring.
Why it's wrong here
Removing the health check from the release pipeline eliminates the automated validation that the deployed application is actually ready to receive traffic, forcing reliance on post-deployment monitoring. Without a health gate, a deployment with a warm-up delay could be marked successful even though the service is still unavailable, degrading release reliability and masking regressions until users or monitoring alerts surface them.
- ✗
Add a retry task that runs the health check again after a failure.
Why it's wrong here
A retry task that re-runs the health check after a failure only repeats the same HTTP readiness probe without addressing the root cause of the intermittent startup delay. Each retry consumes additional pipeline time, and if the application's warm-up period is consistently longer than the configured timeout, the aggregate retry window may still be insufficient, causing the same false-negative failure and an eventual rollback. Retries also cannot extend the per-attempt timeout or improve service readiness, so they risk masking transient conditions while still failing when the underlying issue is genuine.
- ✓
Increase the health check timeout in the pipeline task to 3 minutes.
Why this is correct
Increasing the health check timeout to 3 minutes directly addresses the intermittent startup delay by allowing the deployment to wait longer for the application to become healthy, reducing false-negative failures. The current timeout is too tight for the observed warm-up behavior, so this change accommodates the normal variation without compromising the overall release gate, while still failing if the service genuinely cannot become ready within the allowed window.
- ✗
Reduce the health check timeout to 10 seconds to fail fast and trigger a rollback.
Why it's wrong here
Reducing the health check timeout to 10 seconds would cause the pipeline to fail much more frequently for the same intermittent delay, since the application would almost never meet such a tight deadline. While it would trigger a rollback faster, a rollback is unnecessary when the issue is only a temporary slow startup, and the shortened timeout would not resolve the underlying intermittent condition, leading to unnecessary rollback churn and release instability.
Visual reference
Go deeper
Related to this question
Learn chapter
Designing a Build Pipeline
Key term
Check
A Check in Azure DevOps is a gating mechanism that evaluates predefined conditions before allowing a pipeline deployment to proceed to a specific environment.
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
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.