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

Answer analysis

Option-by-option breakdown

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

• ✗

  Configure the build to use a self-hosted agent with previously restored packages

  Why it's wrong here

  A self-hosted agent may retain a local NuGet global packages folder from previous builds, but Azure Pipelines does not automatically manage or reuse that folder as a cache. The NuGet restore task will still execute dependency resolution, and unless you explicitly configure a cache task or set NUGET_PACKAGES to a dedicated persisted path, there is no guarantee the agent has the required packages or that they won't be evicted. Relying on an implicit, unmanaged local cache is not a reliable optimization.

• ✗

  Use a private agent with a faster network connection

  Why it's wrong here

  Faster network connectivity can reduce the wall-clock time spent downloading NuGet packages from the source, but it does not eliminate the need to run the restore step or the overhead of dependency resolution and package extraction. The restore process still issues HTTP requests, parses nuspec files, and validates package content, so even with low latency you inherit per-package network overhead, throttling, and the risk of transient failures. The build is not sped up meaningfully compared to avoiding downloads via caching.

• ✗

  Use a Microsoft-hosted agent with a larger SKU

  Why it's wrong here

  Microsoft-hosted agents provide only the default image with no pre-seeded NuGet package cache; every job starts on a fresh virtual machine where the global packages folder is empty. Choosing a larger SKU (more vCPUs/memory) only improves compute-bound tasks like compilation and test execution, but it does nothing to reduce the time spent restoring dependencies, because the packages are still absent and must be downloaded. A larger SKU also costs more while providing zero benefit for the restore bottleneck.

• ✓

  Enable the 'Cache' task to cache the NuGet packages folder

  Why this is correct

  The Cache task (Cache@2) persists the NuGet packages folder (typically identified by the NUGET_PACKAGES environment variable) in a distributed cache such as Azure Blob Storage, keyed by a cache key like a hash of the .csproj files or packages.lock.json. On the first build the cache is populated; on subsequent builds the task downloads and unzips the folder into the agent workspace before the restore step, so NuGet finds needed packages locally and avoids network downloads. This reduces restore time significantly and works on both Microsoft-hosted and self-hosted agents, with cache recovery and invalidation handled automatically.

Go deeper

Related to this question