A platform team publishes an internal npm package to an "Azure Artifacts" feed. Many consuming teams should pull only versions that have passed validation and been blessed for general use, while the platform team keeps publishing in-progress builds to the same feed. Which feed mechanism lets consumers subscribe to only the blessed versions without a separate feed?
- AApply a retention policy that deletes any package version below a quality threshold, so only validated versions survive in the feed and consumers therefore receive only the blessed ones.
- BGive each consuming team a personal access token scoped to read only the validated packages, so the token itself filters the feed down to the blessed versions for those consumers.
- CPromote validated versions into the feed's @Release view and have consumers connect to the feed @Release endpoint, so they resolve only versions promoted into that view. Correct
- DPublish each validated version a second time to a separate release feed and have consumers point at that feed, so only blessed versions ever reach the consuming teams.
Why A is wrong: Retention policies prune versions by age or count, not by validation state, and deleting in-progress builds would break the platform team's own workflow, so this does not separate blessed from unblessed versions.
Why B is wrong: A token controls authentication and feed-level permission, not which versions are visible, so it cannot present consumers with a blessed-only subset and would still expose in-progress builds.
Why C is correct: Feed views expose a filtered slice of a single feed; promoting blessed versions into @Release and pointing consumers at that view endpoint gives them only validated versions while the platform team keeps publishing to @Local.
Why D is wrong: A separate feed does isolate blessed versions, but it forces duplicate publishing and re-resolution of the same artifact, which the requirement explicitly rules out by asking to avoid a second feed.