AZ-400 Practice Question: A company uses Azure Pipelines to build a .NET…

Answer analysis

Option-by-option breakdown

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

• ✓

  Cache the NuGet packages and enable caching in the pipeline

  Why this is correct

  The `DotNetCoreCLI`/`NuGetCommand` task with caching uses a cache key derived from the NuGet.config and the project files (or the packages.lock.json), and stores the global packages folder (`~/.nuget/packages`) on the Azure DevOps server. On a cache hit, `dotnet restore` can satisfy package references from the local cache rather than downloading them, cutting restore time from tens of seconds to near zero. The cache is restored to the agent workspace at job startup, so it works across pipeline runs even on hosted agents, which are ephemeral. This directly addresses the network bottleneck that caused the slow builds.

• ✗

  Use parallel jobs in the pipeline

  Why it's wrong here

  Parallel jobs (or parallel pipeline runs) distribute independent pieces across multiple agents to run simultaneously; they can improve throughput when there are many independent jobs, but they do not accelerate the execution of a single linear build. In a typical .NET Core build, the steps (restore, build, test, publish) are sequential and depend on each other; splitting them into parallel jobs would either require complex multi-job orchestration or duplicate work, and the restore step would still download the same packages from NuGet on every agent. Consequently, wall-clock time for a single pipeline run remains dominated by the same network-bound package restore.

• ✗

  Use a self-hosted agent with more CPU

  Why it's wrong here

  A self-hosted agent with additional CPU cores accelerates CPU-bound steps like compilation and packaging, but the observed build time is dominated by network latency and bandwidth when downloading NuGet packages from external feeds. Upgrading the CPU does not increase network throughput or eliminate the need to fetch packages; the restore step will still wait on the same network I/O. Even with a faster processor, MSBuild's restore phase is I/O bound, and compilation is a comparatively small fraction once packages are available. Therefore, this option would not meaningfully reduce overall build duration.

• ✗

  Enable incremental builds

  Why it's wrong here

  Incremental builds (via MSBuild's up-to-date checks or specifying `--no-restore` after a preceding restore) avoid recompiling unchanged projects, but the pipeline's slow stage is the `dotnet restore` that resolves and downloads NuGet packages from the network. Even if compilation is skipped entirely, the restore step must still query the package source and download the .nupkg files from scratch on every new agent or when the cache does not exist; incremental compilation does nothing to avoid that network fetch. The packages are typically the same each time, so an incremental build cannot reduce the time spent waiting on package acquisition.

Go deeper

Related to this question