Three teams need credentials for the same UCS tooling: a solo developer on a laptop, a shared CI runner, and multi-replica production. Which statement identifies the relevant secret approach?
Select an answer to reveal the explanation.
Short Explanation
Secret storage is situational—like choosing a bike lock, a night-drop box, or a bank vault. Laptop keychain, CI secret store, and production vault each fit different constraints; one answer does not rule them all.
Full Explanation
Match the secret store to the constraint: local keychain or gitignored tooling for developer laptops, CI secret stores for pipelines, and vault or platform secrets for multi-replica production. Each audience has different persistence, sharing, and blast-radius needs; one mechanism rarely fits all three for a civic codebase. Forcing every scenario to use the same laptop keychain entry on a shared drive mixes personal and shared custody and does not serve headless CI or scaled prod. Always baking one secrets.json into the image so laptop, CI, and prod “behave identically” distributes production credentials to every environment that pulls the image. Preferring to post credentials in a Webex space for a shared channel creates durable chat copies and no automated injection. Exam caveat: consistency of interfaces (env vars or mounted files) can stay the same across environments while the backing store differs—do not confuse identical app code with identical secret custody. Operational check: document and test three paths—dev reads gitignored/keychain values, CI injects from its secret store, prod mounts vault/platform secrets—and confirm no environment falls back to a committed secrets file.