A Deployment should inject every key from ConfigMap permits-settings as environment variables without listing each key. Which Pod spec pattern does that?
Select an answer to reveal the explanation.
Short Explanation
envFrom is the bulk dump: every ConfigMap key becomes an environment variable in one shot. Hand-picking keys is valueFrom/configMapKeyRef territory. Mounting files is a different delivery style.
Full Explanation
A Deployment that should inject every key from ConfigMap permits-settings as environment variables without listing each key should use envFrom with configMapRef name permits-settings on the container. envFrom projects each ConfigMap data key into an environment variable of the same name, which suits municipal apps whose settings keys evolve without constant manifest edits.
volumeMounts with subPath for each key is not the correct exclusive path to create environment variables; subPath mounts files, and listing each key defeats the bulk-injection goal. args containing $(permits-settings) and relying on shell expansion of the ConfigMap name fails because Kubernetes does not expand ConfigMap object names that way in args. env valueFrom with secretKeyRef pointing at the ConfigMap name as if it were a Secret fails both object type and API semantics.
Exam caveat: envFrom key names must be valid environment variable names; invalid keys can prevent the container from starting. Operational check: apply envFrom configMapRef, restart Pods, use kubectl exec and printenv to verify expected keys, and confirm all permits-settings entries appear as environment variables. In CKAD scenarios involving q195, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.