A city development team committed API keys into a public GitOps repository used for a citizen-services app. Leadership wants a redesign so configuration secrets are not stored in source control. Which solution best remediates that risk?

When API keys for a citizen-services app land in a public GitOps repository, the remediation is architectural, not cosmetic: remove long-lived secrets from source control and retrieve them at runtime from a managed secret store. AWS Secrets Manager or SSM Parameter Store SecureString holds encrypted values; the application’s IAM role is granted secretsmanager:GetSecretValue or ssm:GetParameter on only the needed ARNs, and deployments inject those values into the process environment or SDK calls without committing plaintext. Rotation, auditing via CloudTrail, and least-privilege retrieval become possible once git is no longer the keyring.

Base64-encoding keys in the public repo fails confidentiality by concept—encoding is not encryption, and any viewer can decode the blob in seconds. Emailing plaintext keys to every contractor and pasting them into EC2 user data fails secrecy, rotation, and blast-radius control; user data and mail trails retain copies indefinitely. Committing a second public fork under a folder named private-config fails the same threat model as the original leak: public means public, and folder names confer no access control.

Exam caveat: after moving secrets, rotate every exposed credential immediately—relocating a still-valid leaked key does not close the incident. Operational check: purge keys from git history where policy requires, confirm the repo scan finds no live secrets, prove the app role can retrieve from Secrets Manager/Parameter Store in a private path, and deny interactive users broad secret read except break-glass roles.