What is the safest source-control practice for Kubernetes Secret manifests that hold live production credentials?
Select an answer to reveal the explanation.
Short Explanation
Git remembers forever—don't file the vault combination in the repo history. Keep live Secret values out of source control and inject them at deploy time. Base64 in a committed YAML is still a leaked secret waiting to happen.
Full Explanation
The safest source-control practice for Kubernetes Secret manifests that hold live production credentials is to avoid committing manifests that embed live credential values; use sealed/external secret workflows or CI injection instead. Municipal repositories are widely cloned and audited—plaintext or base64 secrets in git are incidents waiting to happen.
Committing decoded plaintext beside the base64 form so reviewers can diff passwords easily maximizes exposure. Committing only the Secret's UID and resourceVersion while expecting kube-apiserver to rehydrate values from git hooks invents unsupported behavior. Force-pushing Secret YAML into a public mirror so responders can rotate faster publishes credentials to the world and is the opposite of safe practice.
Exam caveat: even private git history retains leaked secrets until rotated and purged; rotation is mandatory after accidental commits. Operational check: remove live Secret manifests from the app repo, store references or sealed forms only, inject at deploy time, and verify the cluster Secret exists without credentials living in git. In CKAD scenarios involving q215, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.