Release v2026.08.19 for a library catalog API must be auditable across Git and the deployment pipeline. Which release-management practice meets that need?
Select an answer to reveal the explanation.
Short Explanation
Auditors want a name on the jar: Git tag plus pipeline label for v2026.08.19. Floating "latest" and chat-only notes are how civic release history vanishes when someone asks what shipped Tuesday.
Full Explanation
Release management for a library catalog API must leave an auditable trail from Git history through the deployment pipeline. Tagging the release commit (for example v2026.08.19) and labeling the corresponding pipeline execution binds source, build, and deploy into one traceable version identity. Municipal auditors and change boards can then answer "what exactly went to production?" without reconstructing chat folklore.
Deploying unlabeled feature-branch commits straight to production fails auditability and bypasses release discipline. Overwriting a floating "latest" tag on every push collapses history so multiple releases share one name and forensic rollback becomes ambiguous. Storing release notes only in chat omits durable Git tags and pipeline labels that survive personnel changes.
Exam caveat: tagging and labeling are lightweight practices expected of Associate developers; you are not asked to design a full enterprise release-train product, only to make versions traceable end to end.
Operational check: after shipping v2026.08.19, verify the Git tag points at the deployed commit SHA, the pipeline execution carries a matching label or description, and the production artifact metadata references that same version before closing the library release ticket.