You edit a Kubernetes ConfigMap that a running Deployment already consumes. Which of its consumers pick up the new values without a Pod restart, which never do, and roughly how long does propagation take?

## The question behind the question Interviewers ask this because "I changed the ConfigMap and nothing happened" is one of the most common Kubernetes support tickets. Answering it well requires separating three distinct steps: the API object changing, the container's view of it changing, and the application acting on it. Only the middle step is Kubernetes' job, and it only happens for some consumption forms. ## What the kubelet actually does When a Pod mounts a `configMap` volume, the kubelet on that node must keep the mounted content in sync with the API object. It does this in the same loop that reconciles the Pod. Modern kubelets use a *watch*-based strategy by default (`configMapAndSecretChangeDetectionStrategy: Watch`): the kubelet holds a watch on the ConfigMaps its Pods reference, and updates arrive as the API server pushes them. Alternative strategies exist — `Cache` (TTL-based, default TTL one minute) and `Get` (read straight through) — and a kubelet configured with `Get` puts noticeably more load on the API server. The write itself is deliberately atomic. The mounted directory is not a flat set of files; it contains a hidden timestamped directory such as `..2026_08_12_10_31_00.123456789/` holding the real files, a symlink `..data` pointing at it, and one symlink per key pointing into `..data`. To publish an update the kubelet writes a brand-new timestamped directory, then swaps `..data` with an atomic rename, then removes the old directory. A reader either sees the entire old set or the entire new set, never a mixture. This also explains why the mount looks odd to tools that walk directories or that dislike symlinks, and why file watchers must watch the *directory* (or handle symlink replacement) rather than the inode of a single file — an inotify watch on the file itself will go silent after the first swap. **Timing.** Total latency is the kubelet's detection delay plus its sync period. In practice people quote "up to about a minute"; the documented worst case is kubelet sync period + cache TTL. It is never synchronous with your `kubectl apply`, so any test that checks the file immediately after the edit will look like a failure. ## What never propagates **Environment variables.** `envFrom.configMapRef` and `env[].valueFrom.configMapKeyRef` are evaluated by the kubelet exactly once, when it constructs the container. The values are handed to the container runtime as part of the process environment. Nothing in Linux lets an outside party rewrite another process's environment, so the only way to change them is to create a new container — that is, delete the Pod or roll the Deployment. **`subPath` mounts.** `volumeMounts[].subPath` exists to project a single file into a directory without hiding that directory's other contents — for example putting `my.cnf` into `/etc/mysql/` without shadowing everything else. It is implemented as a bind mount of one path inside the volume, taken at container start, and it is explicitly documented as not receiving updates. If you need both single-file placement and updates, mount the whole volume in a sibling directory and symlink, or use `subPathExpr`-free layouts, or accept a restart. (Since Kubernetes 1.33, mounting a ConfigMap or Secret volume `readOnly` no longer blocks updates; the `subPath` restriction is the one that persists.) **Immutable ConfigMaps.** Setting `immutable: true` makes the API server reject any change to `data`; the object must be replaced under a new name. Nothing to propagate, by design — and the kubelet stops watching it, which is the performance benefit. ## Propagation is not reload Even a perfectly refreshed file changes nothing if the process read its configuration at startup and never looks again. Options, in rough order of preference: 1. **Force a new Pod.** Put a hash of the ConfigMap content in the Pod template as an annotation, or generate the ConfigMap with a content-hash suffix in its name (Kustomize's `configMapGenerator` does this). Any change alters the Pod template, which triggers a normal rolling update with health checks and rollback. 2. **Native reload.** Some servers watch their config file (Envoy, Prometheus with a reload endpoint, nginx with `SIGHUP`). A tiny sidecar can watch the directory and hit the reload endpoint. 3. **A reload controller.** Operators such as Reloader watch referenced ConfigMaps and patch the Deployment for you. Option 1 is the one to advocate in an interview: it makes configuration part of the versioned, health-checked, rollback-able rollout instead of an invisible side channel. Live volume updates skip readiness probes entirely — a bad config value can be applied to every replica simultaneously with no canary and no automatic revert. ## Debug checklist Is the consumer an env var? Is the mount using `subPath`? Is the ConfigMap immutable? Did you wait a minute? Does `kubectl exec` show the new file content (proving propagation worked and the app is the problem)? Are you editing the right object in the right namespace — a hashed-name generator may have created a *new* ConfigMap the Pod does not reference.