AZ-400 Practice Question: Design and implement build and release pipelines
Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?
⚠ Common exam trap
Candidates often confuse build-level retry mechanisms (like retention policies or parallel jobs) with step-level retry logic, assuming Azure Pipelines automatically handles transient failures when it does not.
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
✓
Add a PowerShell task that wraps the NuGet restore in a retry loop
Adding a PowerShell task that wraps the NuGet restore command in a retry loop directly addresses transient network failures by reattempting the download. This approach is lightweight, customizable (e.g., using `Start-Sleep` between retries), and does not require changing pipeline architecture or relying on external infrastructure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a PowerShell task that wraps the NuGet restore in a retry loop
Why this is correct
Wrapping the NuGet restore in a PowerShell task enables you to implement a retry loop that checks exit codes and repeats the restore operation on transient failures (e.g., HTTP timeouts or package source throttling), while allowing the build to fail after a defined number of attempts. This directly addresses the intermittent nature of the failure without requiring changes to the pipeline's parallelism or deployment topology.
- ✗
Increase the number of parallel jobs to average out failures
Why it's wrong here
Increasing the number of parallel jobs simply runs more build agents concurrently; it does not retry a failed restore within the same build. A transient failure on one agent will still fail that job, and the overall build result will be failed if any job fails, so parallelism does not mitigate intermittent restore errors.
- ✗
Use a deployment group to deploy the build to a staging environment
Why it's wrong here
Deployment groups are used to target release deployment agents for deploying artifacts to environments, not to run build-time restore operations. Configuring a deployment group has no effect on the NuGet restore task that executes in the build pipeline and cannot introduce retry logic.
- ✗
Configure a build retention policy to automatically retry failed builds
Why it's wrong here
Build retention policies control how long completed builds and their artifacts are retained in Azure DevOps, not whether failed builds are retried. Setting a retention policy does not schedule re-runs or add retry behavior, so it cannot address intermittent restore failures during the build.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Task
A Task in Azure DevOps is a predefined, reusable step that performs a specific action during a build or release pipeline, like compiling code or running tests.
Key term
Azure Pipelines
Azure Pipelines is a cloud-based CI/CD service from Microsoft that automatically builds, tests, and deploys code to any platform or cloud.
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.