Set the vulnerable CodeArtifact package version to archived and allow direct publishing while blocking upstream operations
A company has set up AWS CodeArtifact repositories with public upstream repositories. The company's development team consumes open source dependencies from the repositories in the company's internal network. The company's security team recently discovered a critical vulnerability in the most recent version of a package that the development team consumes. The security team has produced a patched version to fix the vulnerability. The company needs to prevent the vulnerable version from being downloaded. The company also needs to allow the security team to publish the patched version. Which combination of steps will meet these requirements? (Choose two.)
Community Votes
72% of anonymous learners picked answer CD. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Archived is the only status that both removes the version from listings and makes its assets non-downloadable, which is exactly what preventing consumption requires; Unlisted still permits download if the version is already referenced in a lock file, and Disposed permanently deletes assets irreversibly (C). Publishing the patched version requires flipping origin control to allow direct publishing and block upstream operations (D). The status 'deleted' is not a package version status at all, and deletion is a separate API operation rather than a status, so B is invalid.
A critical vulnerability was found in the most recently consumed version of a package that the repository pulls from a public upstream, and the vulnerable version must stop being downloadable while the security team publishes a patched version. Setting the affected package version's status to Archived makes its assets impossible to download and removes it from version listings, which blocks client consumption. Because the repository reaches the package through an upstream external connection that would normally prevent publishing an existing public version, the origin control settings must allow direct publishing while blocking upstream operations so the security team can publish the patched version.
Setting the version status to deleted (B) — deleted is not a valid CodeArtifact package version status; the documented statuses are Published, Unfinished, Unlisted, Archived, and Disposed, so this option describes an operation rather than a status. Setting it to unlisted (A) — unlisted only removes the version from the listings returned to package managers while its assets remain downloadable, so a developer with the version pinned in a package-lock.json or requirements.txt can still install it, which fails the requirement to prevent the vulnerable version from being downloaded. luisfsm_111 and ApacheKafkaAWS argued for deletion on the grounds that archiving seems insufficient for a vulnerability, but archived already blocks the download itself and can be reversed, whereas deleting the version removes the ability to manage it through status updates.
Community Discussion (12 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The requirement is to prevent the vulnerable version from being downloaded while still allowing the security team to publish a patched version. AWS CodeArtifact documents Archived as a package version status whose assets can no longer be downloaded, which is removed from version listings, and whose consumption by clients is therefore blocked; unlike Unlisted, where the assets remain downloadable by anything that already references the version such as a lock file, Archived stops retrieval outright (C). Because the repository obtains this package through an upstream external connection, and CodeArtifact prevents publishing a version that is reachable through an upstream repository, the origin control settings must be changed to allow direct publishing and block upstream operations, which lets the security team publish the patched version into the repository that consumes it (D).Why the Other Options Are Wrong
A proposes setting the status to unlisted. Per the CodeArtifact package version status documentation, unlisted assets are still available for download from the repository; only the version listing omits them, so a build whose lock file already references that version can still install it. That fails the requirement to prevent the vulnerable version from being downloaded. B proposes setting the status to deleted. Deleted is not a package version status; the documented statuses are Published, Unfinished, Unlisted, Archived, and Disposed. Removal is performed through the DeletePackageVersions API, which is an operation rather than a status, so the option as written is not valid. E proposes blocking direct publishing and allowing upstream operations, which is the inverse of what is needed and would leave the security team unable to publish the patched version into the consuming repository. C and D are the correct combination.Community Comment Notes
Community voted C,D (72), with B,D a 28 percent minority. BvGVAXeAMP and Weninka quoted the CodeArtifact package version status documentation establishing that deleted is not a valid status and that archived is what prevents download, while unlisted still allows it. aws_god independently confirmed there is no delete version status. luisfsm_111 and ApacheKafkaAWS preferred deletion, arguing that archiving an insecure version is insufficient, but archived already blocks the download and remains reversible through UpdatePackageVersionsStatus, whereas deletion removes the version's assets entirely.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →