A pipeline that protects the artifact and the secret
A fictional team builds a release candidate, tests it and then rebuilds from the same source branch during production deployment. Its dependency ranges are not locked, so the second build can obtain different packages. The deployment script also contains a shared API secret in plain text inside the repository. A test has recently failed only in production, and the team wants to fix the uncertainty without bypassing security review. It has access to an artifact store, a supported secret-management mechanism and a staging environment, but no permission to deploy in this written exercise. The team must describe a safer process, including what remains different between environments. No particular vendor command, paid service price or guarantee of perfect reproducibility is supplied.
1. Explain an appropriate artifact and dependency change.
Read the worked answer
Build and identify an artifact once, verify it and promote that same artifact through approved environments. Use a reviewed dependency-locking process and record build inputs. Configuration and secrets may vary by environment, but an untracked rebuild should not silently change the candidate.
2. Explain how to handle the exposed secret and its replacement.
Read the worked answer
Follow the authorized incident process to revoke or rotate the exposed credential, investigate use and remove the inappropriate secret from active configuration. Use controlled secret references and least-privilege access; deleting a visible line does not erase repository history or make the old credential safe.