Inject Config via Env, Volumes and Immutable Objects

Why this matters

Images must stay environment-blind: the same digest runs in staging and production or promotions mean nothing. ConfigMaps carry plain settings, Secrets carry sensitive ones (base64-wrapped, etcd-encrypted at rest when configured), and the pod spec decides how each value arrives. The exam tests the channels constantly because hardcoded config is how staging leaks into production.

Concepts

Env vars suit small scalars: envFrom slurps a whole ConfigMap or Secret, valueFrom picks single keys (including fieldRef for pod metadata like namespace and IP). Volume mounts suit files and trees: whole objects land as files, updating on kubelet sync without restarts. Command args suit flags the entrypoint already parses. Pick per consumer, not per habit.

Immutable ConfigMaps and Secrets (immutable: true) freeze data at creation: no edits, ever, which kills an entire class of midnight surprises and speeds kubelet delivery (watched objects skip polling). Changes mean new objects plus updated references, which is exactly the versioned-config discipline production wants.

Rotation without rebuilds: update the object (or swap the immutable version), then kubectl rollout restart the Deployment so pods pick it up. Secrets additionally deserve RBAC scoping plus encryption-at-rest plus short lifetimes, because base64 is encoding, not protection.

Worked example

One app, three channels, rotation by rollout:

apiVersion: v1
kind: ConfigMap
metadata: { name: shop-cfg }
immutable: true
data: { LOG_LEVEL: info, PAGE_SIZE: "50" }
---
# deployment snippet
env:
- { name: LOG_LEVEL,
    valueFrom: { configMapKeyRef: { name: shop-cfg, key: LOG_LEVEL } } }
volumeMounts:
- { name: cfg, mountPath: /etc/shop }
# rotate: new object, new reference, restart
kubectl create configmap shop-cfg-v2 --from-literal=LOG_LEVEL=debug --dry-run=client -o yaml | kubectl apply -f -
# edit deployment reference to shop-cfg-v2, then:
kubectl rollout restart deployment/shop
kubectl rollout status deployment/shop

The rollout is the rotation receipt: new pods carry new values, old pods drain away, and the immutable trail shows exactly which config each revision ran.

Exam notes

Secret values are base64, not encrypted by display: decode before comparing, and never paste real ones into shared terminals. envFrom fails the pod when the source object is missing: create config before workloads, always. And immutable objects cannot be edited even to fix typos: the fix is a new version, which is the discipline working as designed.