An app needs both a private registry pull credential and a database password. Which Secret-type guidance is correct?
Select an answer to reveal the explanation.
Short Explanation
Different locks for different doors: dockerconfigjson for pulling images, Opaque for the app's DB password. Mixing them into one bootstrap token or a TLS Secret type just muddies the purpose. ConfigMaps still aren't for passwords.
Full Explanation
When an app needs both a private registry pull credential and a database password, use a kubernetes.io/dockerconfigjson (docker-registry) Secret for image pulls and an Opaque Secret for the database password. Different Secret types match different consumption paths: imagePullSecrets versus env/volume refs for app credentials in municipal Deployments.
Storing both registry auth and database password in a single bootstrap.kubernetes.io/token Secret only misuses bootstrap token Secrets and conflates unrelated credentials. Putting registry pull auth in a ConfigMap and the database password in a ServiceAccount token automatically fails confidentiality and mechanism—ConfigMaps are wrong for registry auth and SA tokens are not database passwords. Using type kubernetes.io/tls for the database password fails because TLS Secrets are for certificate pairs, not arbitrary DB passwords.
Exam caveat: imagePullSecrets can also be attached on a ServiceAccount to avoid repeating pull refs on every Pod. Operational check: create docker-registry and Opaque Secrets separately, wire imagePullSecrets and env/volume refs, pull the private image, and confirm the app connects to the database. In CKAD scenarios involving q216, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.