You are adopting GitOps. Someone asks how secrets work, since the repository is the source of truth. What are the options and which do you choose?

What the interviewer is testing

Whether you know that plaintext in Git is not an option and can compare the real alternatives on their operational properties.

Why the naive answer fails

Committing secrets to Git puts them in every clone, every fork, every backup, and in history forever — so rotation after exposure means rewriting history across every copy, which does not happen. Even a private repository is readable by everyone with repository access, which is a much larger population than should hold production credentials.

The options

Sealed secrets. Encrypt with a public key whose private half lives only in the cluster; the encrypted blob is safe in Git. Simple, self-contained, and the weakness is key management — rotating the cluster key means resealing everything, and disaster recovery must restore the key.

Encrypted files with a KMS-backed key. Similar, using a cloud key management service, so key rotation and access control are handled by the provider and access is audited. Good fit for cloud estates.

External secrets operator. Git holds a reference, not the secret; an operator fetches the value from the secret manager and creates the runtime secret. Nothing sensitive is in the repository at all, rotation happens in the secret manager without touching Git, and the audit trail is in one place.

Workload identity with no Kubernetes secret at all. The application fetches its credentials directly using its platform identity. Strongest, because there is no stored secret anywhere, and it requires application support.

The choice

External secrets operator as the default, with workload identity wherever the application supports it. The deciding property is that rotation must not require a Git commit — a model where rotating a database password means a pull request will not be exercised at the frequency good hygiene requires.

What a strong answer adds

Noting what GitOps genuinely improves here: the deployment credential leaves CI entirely, because the in-cluster agent pulls rather than an external system pushing. That removes one of the most attractive targets in the estate, and it is a stronger security argument than the secret storage question.

Also: whatever is chosen, the repository still needs branch protection and required review, because with GitOps a merged commit is a production change.

Common weak answers

Sealed secrets chosen without considering rotation. Treating a private repository as sufficient protection.