Automation needs credentials, but hardcoding them is a top cause of breaches. The rules:

• Never commit secrets to a repo — they live forever in git history
• Read secrets from the environment or a secrets manager at runtime
• Keep them out of logs, process lists, and error messages
• Prefer short-lived credentials and workload identity over static keys

For local dev, a git-ignored .env file is fine; in production, inject from Vault, AWS Secrets Manager, Azure Key Vault, or the CI platform’s encrypted store.

# Bad: secret in code and visible in process list
curl -H "Authorization: Bearer sk_live_abc123" https://api...

# Good: from the environment
export API_TOKEN="$(vault kv get -field=token secret/api)"
curl -H "Authorization: Bearer $API_TOKEN" https://api...

# .gitignore the env file
echo ".env" >> .gitignore
set -a; source .env; set +a        # load vars without echoing them

import os
token = os.environ["API_TOKEN"]    # fail loudly if missing, never hardcode

1. Move a hardcoded token into an environment variable and read it in a script.
2. Add a .env file to .gitignore and confirm git ignores it.
3. Explain why passing a secret as a CLI flag is risky.
4. Describe how a secrets manager improves on a static .env file in production.

• ↗ 12-Factor App — Config