Two ways to consume a ConfigMap in a Pod

WHAT THIS TESTS Knowing the two consumption mechanisms and, more importantly, when each is appropriate, including the live-update distinction.

A GOOD ANSWER COVERS Method one is environment variables. You map individual ConfigMap keys to env vars using valueFrom with configMapKeyRef, or import all keys at once with envFrom. This is convenient for a small number of simple scalar settings the app reads from the environment, such as LOG_LEVEL or FEATURE_X_ENABLED. The catch is that environment variables are resolved when the container starts and do not change if the ConfigMap is later updated; you must restart the Pod.

Method two is mounting the ConfigMap as a volume. Each key becomes a file inside a mounted directory, with the value as the file contents. This suits configuration files, for example mounting an nginx.conf or application.yaml into the path the app expects. A key advantage is that volume-mounted ConfigMaps are updated in place by the kubelet (after a short delay), so an app that re-reads the file can pick up changes without a restart.

COMMON WRONG ANSWERS Knowing only the env-var method. Claiming env vars update live when the ConfigMap changes. Forgetting subPath mounts do not get live updates.

LIKELY FOLLOW-UPS Which gives live reload? The volume mount. How to roll env changes? Restart the Deployment. How to mount a single key? Use items to project specific keys. Combine with Secrets? Same two patterns apply.

ONE CONCRETE EXAMPLE An app reads LOG_LEVEL from an environment variable sourced via configMapKeyRef, set once at startup. The same Pod mounts a ConfigMap as a volume at /etc/app, where the key app.yaml becomes the file /etc/app/app.yaml; editing that ConfigMap key updates the file in the container without recreating the Pod.