Courseiva
Question 63 of 823
Design and implement build and release pipelineshardMultiple ChoiceObjective-mapped

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 →

How Courseiva writes practice questions · Editorial policy

Last reviewed: Jun 11, 2026

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.

Loading comments…

Sign in to join the discussion.

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.