In production, a multi-replica civic API must read a Webex bot token at runtime. Which secret storage approach fits that scenario?
Select an answer to reveal the explanation.
Short Explanation
Production replicas should draw tokens from a vault or mounted platform Secret—like badges from a secure desk—not a sticky note text file beside the binary.
Full Explanation
At runtime the process should read tokens from a vault or from a platform Secret object that the CD pipeline mounts. Credentials then stay outside the image layers and can be rotated for the civic bot or API without rebuilding or redistributing artifacts. Copying a plaintext secrets.txt next to the binary on each VM trusts ad-hoc file permissions alone and invites sprawl and inconsistent copies across hosts that drift out of sync. Compiling the bot token into a Python constant shipped in container image layers freezes the secret into every registry pull and build cache, including environments that should never see production credentials. Emailing the token to on-call for interactive paste after every restart does not scale, creates mail archives of secrets, and breaks unattended restarts during patch windows. Exam caveat: mounted files and environment variables can still leak via debug endpoints or crash dumps—combine injection with restricted RBAC and disable secret echo in application diagnostics. Operational check: deploy an image that contains no secret material, confirm the mount or vault agent supplies the token, restart the process, and verify authentication still succeeds using only the injected source.