Tax-portal releases must ensure production always pulls the exact build that was tested. Which artifact practice supports that?
Select an answer to reveal the explanation.
Short Explanation
Immutable versioned artifacts are like sealed evidence bags with case numbers—what you tested is what you ship. Mutating latest under you is how surprises sneak into tax season.
Full Explanation
Tax-portal releases must ensure production always pulls the exact build that was tested. Publishing immutable versioned artifacts supports that guarantee: once a version or digest is released, its bits do not silently change underneath production pulls. CI tags immutable versions (or pins digests) so the artifact validated in test is the artifact promoted. For municipal tax systems, that provenance matters for auditability and for avoiding surprise code changes during filing season.
Overwriting the same mutable latest tag so prod silently receives new bits fails by concept: latest moves, so yesterday’s tested image may not be what prod pulls tomorrow. Allowing anyone to replace release blobs without version history fails integrity and audit requirements. Rebuilding from developer workstations directly into production nightly fails reproducibility and bypasses the controlled CI artifact path entirely.
Exam caveat: immutability means the specific versioned object does not change; retagging mutable aliases is the anti-pattern. You may still publish new versions—just do not mutate the version production already certified.
Operational check: publish tax-portal artifacts with unique version tags or digests, freeze those references through test gates, configure production to pull by digest/immutable tag, deny overwrite on release repositories, and audit any attempt to move latest under a release already in production.