A city transit API pipeline must promote one build through test, staging, and production with approvals between stages. What CodePipeline practice ensures the same artifact moves across those environments?
Select an answer to reveal the explanation.
Short Explanation
One stamped crate rides the whole train—test, staging, then prod—with conductors (approvals) between cars. Rebuilding in every station invents a new crate and ruins the "what we tested is what we ship" promise.
Full Explanation
When a city transit API must move one build through test, staging, and production with approvals between stages, the critical CodePipeline practice is artifact reuse: later stages consume the build output produced earlier instead of recompiling from whatever source tip happens to exist at promotion time. Approvals gate human judgment between environments, but the crate on the conveyor must remain the same stamped artifact so staging validation actually predicts production behavior for rider-facing APIs.
Rebuilding the application from source in every stage fails because each compile can pull different dependency resolutions or newer commits, destroying the "same bits" guarantee. Allowing each stage to pull a different commit hash intentionally diverges environments and makes approvals meaningless for correctness. Skipping artifacts and redeploying a developer's branch tip abandons pipeline provenance entirely.
Exam caveat: promotions should move immutable artifacts; environment-specific configuration may still differ via parameters, but the application revision under test should not be secretly rebuilt.
Operational check: inspect the pipeline's artifact store and stage inputs, confirm the production deploy action references the same artifact identifier that staging validated, and verify approval history shows human gates without opportunistic rebuilds between transit environments.