AZ-400 Question 101
Single answerYou are configuring Azure Artifacts feeds for an organization that develops multiple .NET services. The team wants to store internal packages in a dedicated feed while also retrieving stable packages directly from NuGet.org. However, they need to ensure no pre-release packages from NuGet.org are exposed to the broader development team. Which approach should you take to achieve this requirement?
- A
Create one feed in Azure Artifacts and set NuGet.org as an upstream source. Then configure separate package views (e.g., @Prerelease and @Release) to expose stable packages to most developers while isolating pre-release builds in another view.
- B
Create two separate feeds: the first for local packages only, and the second that directly references NuGet.org. Require each developer to switch feeds manually based on whether they want stable or pre-release packages.
- C
Enable public package consumption in the local feed without configuring any upstream sources. Use NuGet CLI to clone stable packages from NuGet.org into the local feed whenever required.
- D
Use Azure Repos to store internal packages in version control, then configure a single feed in Azure Artifacts pointing only to NuGet.org without any views.
Show answer and explanation
Correct answer: A
Explanation
Using Azure Artifacts with upstream sources allows an organization to consume packages from public and private feeds seamlessly. Configuring separate views such as @Prerelease and @Release is a recommended best practice, as documented by Microsoft (e.g., docs.microsoft.com/azure/devops/artifacts). This approach ensures only stable packages reach production pipelines or the broader development team, while pre-release versions are isolated for testing and experimentation.
- A. Correct.
Option 1 is correct. A single feed with upstream sources and views is the recommended approach to manage both internal and upstream packages in Azure Artifacts. By creating multiple views, such as @Release for stable packages and @Prerelease for experimental versions, you can control which packages are visible to different groups. This setup avoids any pre-release packages leaking into the main release view.
- B. Incorrect.
Option 2 is incorrect. While two separate feeds can technically work, it complicates the process by forcing developers to toggle between feeds for stable or pre-release versions. It also does not streamline the package lifecycle since these feeds do not share package views, making management more cumbersome.
- C. Incorrect.
Option 3 is incorrect. Manually cloning packages from NuGet.org is error-prone and unsustainable. It defeats the purpose of configuring an upstream source for automatic updates and does not provide a reliable way to filter out pre-release packages.
- D. Incorrect.
Option 4 is incorrect. Storing packages in Azure Repos is not a best practice for binaries, and failing to configure upstream sources or views means you cannot effectively control which packages (stable vs. pre-release) flow into the feed.