An application expects configuration as files under /etc/app. How should a ConfigMap typically provide those files, and what must developers remember about updates?
Select an answer to reveal the explanation.
Short Explanation
A ConfigMap volume is like dropping printed settings sheets into a folder the app already reads. New sheets can show up later, but the app might need a nudge (reload/restart) before it notices.
Full Explanation
When an application expects configuration as files under /etc/app, mount a ConfigMap as a volume so keys appear as files in that directory. Developers must remember that many processes read configuration only at startup: Kubernetes can update projected files when the ConfigMap changes, but running processes may still need a reload or Pod restart to pick up new municipal settings.
Storing the ConfigMap only in emptyDir so Kubernetes never projects files abandons the ConfigMap volume feature. Encoding the ConfigMap into a Service annotation that the runtime mounts automatically is not how configuration injection works. Replacing the ConfigMap with a PVC because “config files cannot be volumes” is false—ConfigMap volumes are standard.
Exam caveat: Distinguishing envFrom versus volume mounts; subPath mounts may not auto-update; immutable ConfigMaps change the update story. Prefer ConfigMaps for non-secret config.
Operational check: kubectl create configmap; mount it; kubectl exec -- ls /etc/app; update the ConfigMap; observe file contents vs whether the app reloaded; roll Pods if the process caches config. 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.