Production for a tax-portal release must deploy the exact build artifact that passed staging. Which practice preserves that guarantee?
Select an answer to reveal the explanation.
Short Explanation
What passed staging should be the same bits in prod—promote the sealed crate, do not bake a fresh cake from "almost the same" ingredients. Rebuilds invent a stranger in production.
Full Explanation
Production for a tax-portal release must deploy the exact build artifact that already passed staging. Promoting that immutable artifact—without rebuilding—preserves the guarantee that production runs the same bits staging validated. Pipelines should pass artifact identifiers forward so citizen tax flows do not silently diverge between environments after a "successful" staging test.
Rebuilding binaries from staging's approximate source tree again in production reintroduces nondeterminism through dependency resolution, newer commits, or different build hosts. Allowing production to compile whatever is on HEAD at deploy time explicitly breaks correlation with the staging-tested commit. Replacing artifacts with handwritten scripts pasted into the production console abandons provenance and repeatability for finance systems.
Exam caveat: immutable artifact promotion is a core CI/CD correctness theme on DVA-C02; environment-specific configuration may differ via parameters, but the application revision should not be secretly recompiled.
Operational check: compare artifact checksums or pipeline artifact IDs between staging and production deploy actions for the tax portal, fail the release if they differ, and document the promoted version for finance change records.