A ConfigMap holds several keys, but the app only needs app.properties as one file inside an existing config directory that already has other files. What should the volumeMount use?
Select an answer to reveal the explanation.
Short Explanation
Dropping a whole ConfigMap volume on a folder is like dumping a moving box on a tidy desk—it covers everything. subPath is the “place just this one sheet” trick: one key lands as one file and the rest of the directory stays put.
Full Explanation
When a ConfigMap holds several keys but the app only needs app.properties as one file inside an existing config directory that already has other files, use volumeMounts.subPath set to the ConfigMap key. subPath projects only that file into the directory without replacing or hiding sibling files the municipal app still needs.
defaultMode 0777 does not prevent directory replacement and weakens permissions. subPathExpr with a wildcard so every key merges is not how you select a single key cleanly. Mounting the ConfigMap as envFrom injects environment variables, not a single file beside existing directory entries.
Exam caveat: subPath mounts historically do not auto-update when the ConfigMap changes—plan rollouts for config updates. Without subPath, a ConfigMap volume mounts as a directory containing all keys.
Operational check: mount with subPath: app.properties to /etc/app/app.properties; kubectl exec -- ls /etc/app and confirm siblings remain; update the ConfigMap and verify whether a rollout is required for the process to see changes. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.