A Deployment injects Secret keys with envFrom.secretRef. After you update the Secret data, application processes still show the old values. What should you expect?
Select an answer to reveal the explanation.
Short Explanation
Env vars are stamped at birth—updating the Secret later doesn't rewrite a running process's environment. Roll the Deployment or restart Pods to pick up new values. Volume mounts can refresh files; envFrom is a different story.
Full Explanation
When a Deployment injects Secret keys with envFrom.secretRef and you update the Secret data, application processes typically still show the old values because environment variables taken from Secrets are fixed at container start; a rollout or Pod restart is required to load new values. Municipal credential rotations must include a restart plan, not only a Secret patch.
Claiming kubelet rewrites every running process environment in place within sixty seconds of a Secret patch fails—process environments are not hot-patched that way. Claiming updating a Secret always deletes and recreates every Pod in every namespace automatically overstates and invents cluster-wide behavior. Claiming envFrom Secrets hot-reload like projected volume files without any Pod restart ever confuses env injection with file projection update semantics.
Exam caveat: mounted Secret volumes can update differently than env vars; know which consumption path your app uses before promising live rotation. Operational check: patch the Secret, confirm env inside the container is unchanged, rollout restart the Deployment, and verify new values appear after restart. In CKAD scenarios involving q217, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.