Design and implement build and release pipelines →mediumMultiple ChoiceObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. 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

✓

Add a CacheBeta task before the restore step to cache the packages folder.

The CacheBeta task enables caching of the NuGet packages folder between pipeline runs, avoiding repeated downloads from the feed. This directly reduces build time. Option A is wrong because while self-hosted agents can have persistent storage, the question specifies using a Microsoft-hosted agent, and the CacheBeta task works even with Microsoft-hosted agents. Option B is wrong because using upstream sources in Azure Artifacts does not cache packages locally on the agent; it still requires downloading them each time. Option C is wrong because increasing compute resources does not affect the time spent downloading dependencies; caching addresses the root cause.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use a self-hosted agent with persistent storage.
Why it's wrong here
While a self-hosted agent with persistent storage can cache NuGet packages locally and avoid re-downloading them on every build, it is not a quick fix because it requires provisioning, securing, and maintaining dedicated infrastructure. The cache is tied to that specific agent's file system, so it does not help if builds run on different agents or if the agent is replaced, and you lose the simplicity and elasticity of Microsoft-hosted agents. For a fast, built-in solution, Azure Pipelines' Cache task provides a managed, key-based cache that works across hosted agents without any infrastructure overhead.
✗
Use a hosted Azure Artifacts feed with upstream sources.
Why it's wrong here
Upstream sources in a hosted Azure Artifacts feed only proxy external packages (like NuGet.org) through the feed, but they do not cache those packages locally on the build agent. Each build still downloads the package onto the ephemeral agent's workspace, so network transfer time is not avoided, making this ineffective for speeding up restores.
✗
Increase the agent's compute resources by selecting a higher SKU.
Why it's wrong here
Upgrading to a higher SKU increases CPU and memory but does not increase network bandwidth or latency to package servers. Since the pain point is re-downloading the same packages on every build, extra compute resources leave the network bottleneck untouched and provide no benefit for reducing restore time.
✓
Add a CacheBeta task before the restore step to cache the packages folder.
Why this is correct
Adding a CacheBeta task (or the newer Cache task) with a key based on the packages file (e.g., packages.lock.json or .csproj) and a path like $(UserProfile)/.nuget/packages stores the restored packages in Azure DevOps' external cache. On subsequent builds, the restore step pulls packages from that cache instead of hitting the network, which directly eliminates repeated downloads and is the correct quick fix.

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Why each option matters

Option-by-option breakdown

Related to this question