Question 63 of 823
AZ-400 Cache NuGet packages Practice Question
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?
⚠ Common exam trap
Test-takers frequently confuse the Cache@2 task's explicit key-path pairing with other NuGet-specific arguments or environment variables, assuming a simpler flag exists, when in fact Azure DevOps requires the Cache@2 task for reliable cross-build caching.
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
✓
Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'
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.
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 the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'
Why this is correct
The Cache@2 task is the correct built-in mechanism for caching NuGet packages in Azure Pipelines. The composite key, combining 'nuget', the agent OS, and packages.lock.json, invalidates the cache only when the OS or the lock file changes, ensuring restore artifacts are reused across runs. The path points to the packages folder (typically the global packages folder) so subsequent restore operations can use the cached packages without hitting the network.
- ✗
Use the NuGetCommand@2 task with the -Cache argument.
Why it's wrong here
NuGetCommand@2 does not support a '-Cache' argument. The task wraps NuGet CLI commands and accepts arguments for restore, pack, or push, but package caching is not a built-in feature of that task, so this option is invalid.
- ✗
Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.
Why it's wrong here
The NUGET_PACKAGES environment variable only redirects the NuGet global packages folder to a custom path; it does not by itself cause caching between pipeline runs. Azure Pipelines does not have a native 'pipeline caching plugin' that automatically persists arbitrary environment-variable-defined folders without an explicit Cache task, so relying on that alone would not provide durable cache restoration across separate pipeline executions.
- ✗
Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.
Why it's wrong here
The DotNetCoreCLI@2 task with the --no-restore flag skips the restore phase entirely, meaning packages would not be restored during the build. Manually copying packages afterward is not an automated caching strategy and would require custom scripting to save and restore the folder, making it an inefficient and error-prone approach compared to Cache@2.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-400 exam frequently reuses these exact scenarios with slightly different constraints.
✓Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'Correct answer▾
Why this is correct
The Cache@2 task is the correct built-in mechanism for caching NuGet packages in Azure Pipelines. The composite key, combining 'nuget', the agent OS, and packages.lock.json, invalidates the cache only when the OS or the lock file changes, ensuring restore artifacts are reused across runs. The path points to the packages folder (typically the global packages folder) so subsequent restore operations can use the cached packages without hitting the network.
✗Use the NuGetCommand@2 task with the -Cache argument.Wrong answer — click to see why▾
Why this is wrong here
NuGetCommand does not have a -Cache argument for cross-build caching.
✗Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.Wrong answer — click to see why▾
Why this is wrong here
The environment variable is useful but caching must be explicitly configured.
✗Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.Wrong answer — click to see why▾
Why this is wrong here
--no-restore skips restore, not caching.
Analysis generated from the official AZ-400blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.