Operators update a ConfigMap that is mounted as files into running Pods. Environment variables were also injected from the same ConfigMap at container start. What should an application developer expect?
Select an answer to reveal the explanation.
Short Explanation
Mounted ConfigMap files can refresh like a shared binder someone swapped pages in — eventually. Env vars are snapshots taken when the container started. Either way, many apps still need a nudge to reread config.
Full Explanation
When operators update a ConfigMap that is mounted as files into running Pods while environment variables were also injected from the same ConfigMap at container start, expect mounted ConfigMap files can update eventually via kubelet refresh, but environment variables keep their startup values unless Pods restart; applications may still need to reload file contents. That split is a classic CKAD caveat for municipal apps that mix env and file consumption from one ConfigMap.
Claiming both mounted files and environment variables always hot-reload instantly with no process support overstates platform and application behavior. Claiming environment variables update live while mounted files never change until the node reboots inverts the usual behavior. Claiming updating a ConfigMap immediately recreates every Pod that references it without further action fails—ConfigMap updates do not automatically roll Deployments.
Exam caveat: either teach the app to watch and reload files or perform a rollout restart when env-derived settings must change. Operational check: update the ConfigMap, observe mounted file contents after a short wait, confirm environment variables still show old values, then rollout restart the Deployment if those env values must refresh.