How should a container receive a single Secret key password from Secret db-creds as the environment variable DB_PASSWORD?
Select an answer to reveal the explanation.
Short Explanation
secretKeyRef is a precise straw: one Secret key poured into one env var. Point valueFrom.secretKeyRef at db-creds / password for DB_PASSWORD. imagePullSecrets and raw Secret names in value don't do that mapping.
Full Explanation
A container should receive a single Secret key password from Secret db-creds as environment variable DB_PASSWORD using an env entry with valueFrom.secretKeyRef naming the Secret and the password key. That projects one sensitive key into one named variable for municipal database clients without mounting every Secret key.
Mounting the entire etcd database read-only and parsing Secret keys from disk dumps is not an application pattern and is operationally absurd. Setting env.value to the plain Secret name and relying on kubelet to dereference keys fails—env.value is a literal string, not a Secret pointer. Adding the Secret name to imagePullSecrets makes registry credentials available for pulls; it does not inject database passwords into the process environment.
Exam caveat: secretKeyRef failures for missing Secrets or keys typically block container start unless marked optional. Operational check: create db-creds with key password, set secretKeyRef on DB_PASSWORD, deploy, exec printenv DB_PASSWORD only in controlled debug, and confirm the app authenticates to the database. In CKAD scenarios involving q212, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.