hardMultiple Choice
Cutting Feature Branch Build Time with Caching and Path-Filtered Analysis
A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?
⚠ Common exam trap
Many candidates confuse 'parallel jobs' or 'faster agents' with solving a network-bound dependency restoration problem, when caching is the only strategy that eliminates the repeated download of unchanged packages.
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
✓
Cache the NuGet packages and enable caching in the pipeline
Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.
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
About these practice questions
Courseiva writes every AZ-400 question from scratch — 696 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 →
Same concept, more angles
8 more ways this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You have a YAML pipeline that uses a multi-stage build. You want to cache the restored NuGet packages across builds to improve performance. Which caching strategy should you use?
hard- ✓ A.Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'
- B.Use the NuGetCommand@2 task with the -Cache argument.
- C.Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.
- D.Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.
Why A: The Cache@2 task is the recommended way to cache NuGet packages in Azure Pipelines. By using a cache key that includes the agent OS and the packages.lock.json file, the cache is invalidated only when the lock file changes, ensuring restored packages are reused across builds. The path points to the NuGet global packages folder, which is typically $(System.DefaultWorkingDirectory)/packages when NUGET_PACKAGES is set.
Variation 2. Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)
hard- A.Add more build steps to the pipeline.
- ✓ B.Enable caching for NuGet packages.
- C.Increase the number of parallel jobs in the pipeline.
- ✓ D.Use multi-stage build with parallel test execution.
- ✓ E.Use a self-hosted agent with pre-installed dependencies.
Why B: Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently. Together, these optimizations improve build performance.
Variation 3. Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?
easy- A.Configure the build to use a self-hosted agent with previously restored packages
- B.Use a private agent with a faster network connection
- C.Use a Microsoft-hosted agent with a larger SKU
- ✓ D.Enable the 'Cache' task to cache the NuGet packages folder
Why D: The best way to improve build performance is to cache the NuGet packages folder using the 'Cache' task in Azure Pipelines. This avoids re-downloading packages on each run. Option A (self-hosted agent) is not guaranteed to cache the packages folder across builds unless caching is explicitly configured. Option B (faster network) may help but doesn't eliminate the restore time. Option C (larger SKU) improves CPU/memory but does not cache packages. Therefore, option D is correct.
Variation 4. You have a YAML pipeline that builds a .NET application. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?
medium- A.CopyFiles task to copy packages to a staging directory.
- B.NuGet restore task with 'cacheRestore' option.
- ✓ C.Cache task with a key based on the packages.lock.json hash.
- D.PublishBuildArtifacts task to upload packages.
Why C: The Cache task in Azure Pipelines allows you to cache NuGet packages by specifying a key derived from the hash of `packages.lock.json`. This ensures that the cache is invalidated only when the lock file changes, which accurately reflects changes in package dependencies. The cached `~/.nuget/packages` folder is then restored on subsequent runs, significantly reducing restore time.
Variation 5. Your build pipeline uses a hosted agent. You notice that every build starts with a clean workspace, increasing build time. You want to improve performance by caching the Node.js 'node_modules' folder. Which task should you add to the pipeline?
easy- A.Publish Build Artifacts task
- B.Copy Files task
- C.Download Build Artifacts task
- ✓ D.Cache task
Why D: The Cache task (option D) is correct because it allows you to cache the 'node_modules' folder between pipeline runs on hosted agents, avoiding the need to reinstall dependencies from scratch each time. By specifying a cache key (e.g., based on package-lock.json) and the path to cache, subsequent builds can restore the folder from cache, significantly reducing build time.
Variation 6. Your team uses Azure Pipelines to build a .NET application. You notice that the build takes 15 minutes because of dependency restoration. You want to cache the NuGet packages to speed up subsequent builds. Which task should you add to your pipeline?
medium- A.DownloadBuildArtifacts task
- B.NuGet restore task with the 'noCache' option set to false
- C.DotNetCoreCLI task with the 'restore' command
- ✓ D.Cache task with a key based on the package lock file
Why D: The Cache task (D) is the correct choice because it allows you to cache the NuGet packages folder (typically `~/.nuget/packages`) based on a key derived from the package lock file (e.g., `packages.lock.json`). This ensures that when the lock file hasn't changed, the cached packages are restored from the pipeline cache instead of being downloaded from the NuGet feed, significantly reducing build time. The key is computed from the lock file's content hash, so any change in dependencies automatically invalidates the cache.
Variation 7. Your pipeline builds a .NET application and runs unit tests. You notice that the pipeline takes too long because it restores NuGet packages on every run. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?
hard- A.NuGetCommand@2 with the restore command
- B.CopyFiles@2
- C.PowerShell@2 to manually download and cache
- ✓ D.Cache@2 (CacheBeta)
Why D: The Cache@2 (CacheBeta) task is specifically designed to cache folders or files between pipeline runs, such as NuGet packages, to reduce restore time. By caching the NuGet packages folder (e.g., $(UserProfile)/.nuget/packages), subsequent builds can skip the full restore and reuse previously downloaded packages, significantly speeding up the pipeline.
Variation 8. Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?
easy- A.PublishBuildArtifacts@1
- B.CopyFiles@2
- C.DownloadBuildArtifacts@0
- ✓ D.Cache@2
Why D: Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.
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.