The utility billing API on OKE needs a database password and an OCIR pull credential at runtime. Where should those credentials live relative to ConfigMaps and the container image?
Select an answer to reveal the explanation.
Short Explanation
Passwords and pull tokens are secrets—store them in a Kubernetes Secret (Vault comes later), not in a ConfigMap or the image. A Secret is still a cluster object, so treat it as sensitive, not as “safe to paste in chat.”
Full Explanation
Database passwords and OCIR pull credentials for the utility billing API are sensitive runtime secrets. They belong in a Kubernetes Secret, with Vault-backed injection as a later hardening step—not in a ConfigMap and not baked into the container image. Secrets are the cluster object intended for credentials; images and ConfigMaps are widely readable, copyable, and easy to leak through reviews and logs. A ConfigMap labeled public so every namespace can read the password in plain YAML reviews maximizes leakage and fails basic secret handling for municipal systems. Dockerfile ENV defaults committed to the application repository put long-lived credentials into git history and image layers where rotation is painful. Annotations on the Service object appear in kubectl describe output to many viewers and are not a credential store. Exam caveat: base64 in a Secret is encoding, not encryption at rest by itself—still restrict RBAC, enable encryption-at-rest where required, prefer external secret managers for strong controls, and never commit Secret manifests with real values to shared repositories. Operational check: mount or envFrom the Secret into the Pod, confirm the app connects to the database and can pull images, and verify the password string does not appear in ConfigMaps, image layers, or Service annotations.