What they're testing
Whether you think about rotation and least privilege, or only about storage location.
The short answer~30 seconds
In a managed secret store with access control and an audit trail: AWS Secrets Manager, GCP Secret Manager, Vault, or your platform's own secrets. The application receives them at runtime through environment variables or a mounted file. More important than the location are three things: separate credentials per environment, least privilege per service, and the ability to rotate without a redeploy.
The long answer
On Kubernetes Secrets there's a widespread misunderstanding: they're base64-encoded, which is to say not encrypted at all — anyone who can read the object reads the value. You need etcd encryption at rest, or an external solution such as the External Secrets Operator pulling from a real store. Raising this usually separates people who've run a cluster from people who've read the docs.
Once a secret reaches git, deleting the commit isn't enough — it's in the history, in forks, and may already have been found by scanning bots within minutes. The correct procedure is ROTATING the credential first, then cleaning the history. Many teams do it in the other order and spend half a day rewriting history while the key is still valid.
The best direction is eliminating static secrets where possible: use workload identity (an IAM role bound to a service account, workload identity federation) so the service obtains short-lived tokens itself. There's no long-lived key to leak, and rotation becomes the platform's problem rather than yours. It's the highest-scoring answer because it removes the cause rather than managing the consequence.
What they'll ask next
?What about secrets in CI?
Use the CI system's own secret store, scoped per environment, and don't expose them to pull requests from forks — that's the classic exfiltration path, since an outsider can submit a PR that runs arbitrary code in your pipeline.
These lose points
- Committing
.env"because it's only dev". Dev keys usually point at real services, and scanning bots don't distinguish. - One credential shared across environments. Then there's no way to revoke staging's access without breaking production.