Task 3.1: Design and implement a package management strategy

• ACreate a second feed for tested packages and have the pipeline push each tested version to it again

  Incorrect

  Pushing the same version to a second feed publishes it twice, which the team wants to avoid.

• BPromote tested versions to the @release view, and point consuming teams at that view

  Correct

  A view exposes only the versions promoted into it, while the base feed still holds everything that was published.

• CPublish tested versions straight to the @release view from the integration test stage

  Incorrect

  Packages can be published only to the base feed (@local); views are read-only and receive packages through promotion.

• DUnlist every untested version so that consumers can't find it in search

  Incorrect

  That doesn't give consumers a curated set of tested versions.

Feed views share a subset of package versions with consumers. Every feed has @local (the default, which receives all published packages and those saved from upstreams) plus suggested @prerelease and @release views. Views are read-only; you publish to the base feed and promote versions into a view.

• ARemove the npmjs.com upstream and have developers add npmjs.com to their .npmrc files as a second registry

  Incorrect

  Two registries in the client configuration make restores nondeterministic, which is exactly how the substitution happens.

• BKeep Allow External Versions turned off for contoso-auth

  Correct

  The setting is off by default and blocks public versions of a name the feed holds privately from being saved to it.

• CMove the npmjs.com upstream to the top of the upstream source list

  Incorrect

  Upstream order changes which source answers first; it doesn't block public versions of a private package's name.

• DGive every developer the Feed Reader role so that nobody can save packages from the upstream

  Incorrect

  Builds still need public packages through the feed, and readers alone can't bring new ones in.

Upstream sources let one feed serve private packages and packages from public registries. The Allow External Versions option, off by default and set per package by a Feed Owner, controls whether versions from public registries can be saved; when a team has a private package, new public versions with the same name are blocked.

• AGive the build service identities the Feed Publisher (Contributor) role on the feed

  Correct

  Feed Publisher can publish, promote and unlist packages, which is what the push step needs.

• BGive the project's Build Service identity the Feed Owner role on the feed

  Incorrect

  Owner also lets the pipeline change feed settings and delete packages, more than publishing needs.

• CCreate a personal access token with Packaging (Read, write, & manage) and use it in the push step

  Incorrect

  A personal token ties the pipeline to one person and carries more rights than one feed needs.

• DGive the build identity the Feed and Upstream Reader (Collaborator) role on the feed

  Incorrect

  That role is assigned by default and doesn't include publishing.

By default, the build service identities get the Feed and Upstream Reader (Collaborator) role, which can read and save from upstreams. A pipeline that publishes needs the Feed Publisher (Contributor) role for the Project Collection Build Service and the project-level Build Service.

• AKeep date versions and add a column for breaking changes to the release notes page

  Incorrect

  Consumers and package tools would still have to read notes; the version itself wouldn't signal a breaking change.

• BA single number that increases by one with every published build of the library

  Incorrect

  A counter shows order but says nothing about compatibility.

• CThe Git commit hash as the whole version string, so that every build can be traced to its source

  Incorrect

  Hashes don't sort and say nothing about the scope of a change.

• DMajor.Minor.Patch, raising Major for breaking changes, with the build date in build metadata

  Correct

  SemVer's major number signals breaking changes, minor and patch signal compatible changes, and metadata can carry the date.

Semantic versioning uses Major.Minor.Patch: major for breaking changes, minor for backward-compatible features and patch for fixes. Dates as versions don't communicate the scope of a change; put them in build metadata instead.

• A2.1.0, because a version without a suffix wins over its prereleases

  Correct

  Prerelease versions sort below the release with the same numbers.

• B2.1.0-beta.2, because it has more parts

  Incorrect

  A suffix doesn't make a version newer.

• CThey're equal, because Major.Minor.Patch match

  Incorrect

  The suffix is part of the version and affects precedence.

• DWhichever was published later

  Incorrect

  Precedence comes from the version string, not publish time.

A prerelease suffix marks a version as not yet stable. When ordering, NuGet follows SemVer and puts a version without a suffix ahead of its prerelease versions.

• APush the deployed image again under the latest tag

  Incorrect

  Re-tagging doesn't protect the image from deletion.

• BTurn off the purge task for the repository

  Incorrect

  That stops cleanup, which the team wants to keep.

• CCopy the image to a second registry before each production release

  Incorrect

  A copy elsewhere doesn't stop the original from being purged.

• DLock the deployed image by setting write-enabled to false

  Correct

  A locked image can't be deleted, while cleanup still removes unlocked images.

The recommended practice is to lock any deployed image tag by setting its write-enabled attribute to false, which prevents its removal while auto-purge or retention policies keep cleaning up other images.

• ADelete the version

  Incorrect

  A deleted version goes to the Recycle Bin and can't be installed.

• BPromote the version to a view

  Incorrect

  Promoting makes it more visible to that view's consumers.

• CLet the feed's retention policy remove it

  Incorrect

  Retention deletes versions, so builds pinned to 3.0.1 would stop restoring.

• DUnlist the version

  Correct

  Unlisting hides it from search results while it stays in the feed.

For NuGet packages you can unlist or delete a version. Unlisting hides it from search results but keeps it in the feed; deleting moves it to the Recycle Bin and makes it unavailable for installation.

• AThe team lacks the Feed Owner role

  Incorrect

  Publishing doesn't need Feed Owner, and the version conflict would block the push whatever the role.

• BThe version already exists in an enabled upstream source

  Correct

  With upstream sources enabled, you can't publish a version that already exists in one of them.

• CThe feed can't hold packages that aren't private

  Incorrect

  Feeds hold both published and upstream packages.

• DVersion numbers must be four parts long

  Incorrect

  NuGet versions don't need four parts.

When upstream sources are enabled on a feed, you can't publish a package version that already exists in one of those upstream sources, for example a version that's already on nuget.org.