Housing-authority casework scripts briefly contained a cloud API key in a working-tree file. What source-control control best stops that secret from being committed?
Select an answer to reveal the explanation.
Short Explanation
A secrets-detection pre-commit hook is the metal detector at the courthouse door — it stops the badge (API key) from walking into the Git lobby. Weekly reminder emails are polite posters; they do not block the commit.
Full Explanation
Housing-authority casework scripts briefly containing a cloud API key in the working tree create a commit risk: once secrets enter Git history—even briefly—they may be pushed and require rotation plus history scrubbing. A pre-commit hook that runs secrets detection and rejects the commit when credentials are found stops the secret at the developer workstation before it becomes a permanent object in the repo.
Weekly reminder emails without technical enforcement do not block a mistaken commit. A post-deploy cron that scrubs secrets only after they reach remote main is too late; exposure and history contamination already occurred. Disabling HTTPS does not prevent local commits of secrets and can weaken transport security for legitimate remotes.
Exam caveat: pre-commit hooks are a control layer—teams should still use secret stores and avoid writing keys to disk; hooks reduce accidents rather than replace vaults. Operational check: stage a dummy credential pattern in a test file, attempt commit, confirm the hook fails the commit, remove the secret, and verify a clean commit succeeds. If a secret somehow bypasses the hook, treat it as compromised: rotate the cloud key, purge history with an approved rewrite process, and notify housing-authority security. Prevention at pre-commit remains cheaper than incident response after a push to the remote.