A .NET team consumes packages from the public NuGet gallery, but a recent outage of that gallery broke their builds, and they also want every external package version that the build ever restored to remain available even if it is later unlisted upstream. Within "Azure Artifacts", which feed capability should they configure to meet both needs?
- AAdd the public NuGet gallery as a separate service connection and point each build's restore step at that connection instead of at the Azure Artifacts feed, so restores skip the feed entirely.
- BConfigure the public NuGet gallery as an upstream source on the feed, so the feed proxies and caches each requested package version and continues serving the saved copy when the upstream is unavailable. Correct
- CCreate a release view on the feed named for the public gallery and promote external packages into that view manually after each build, so a curated copy of every external version is retained.
- DEnable retention policies on the feed with a high keep count, so the feed automatically downloads the public gallery and preserves a copy of each external package version for builds.
Why A is wrong: Pointing restores straight at the public gallery is tempting because it keeps the existing source, but it leaves the build directly dependent on gallery uptime and saves no copy locally, so neither requirement is met.
Why B is correct: An upstream source makes the feed a caching proxy that saves every restored version into the feed, which both insulates builds from upstream outages and retains versions even after they are unlisted upstream.
Why C is wrong: Views filter and label packages that already live in the feed, and manual promotion of every external version is unworkable, so a view cannot proxy the gallery or guarantee automatic retention.
Why D is wrong: Retention policies only decide which already-stored package versions are pruned, so they neither fetch from the public gallery nor proxy it during an outage, leaving the outage requirement unmet.