Several Deployments should pull from a private registry without repeating pull-secret references on every PodSpec. What ServiceAccount technique helps?
Select an answer to reveal the explanation.
Short Explanation
Hang the registry keyring on the ServiceAccount once, then any Pod wearing that SA can pull. That beats copy-pasting imagePullSecrets into every Pod template. Namespace annotations and LimitRanges aren't the pull-secret inheritance path.
Full Explanation
When several Deployments should pull from a private registry without repeating pull-secret references on every PodSpec, attach the docker-registry Secret under the ServiceAccount's imagePullSecrets, then run Pods using that ServiceAccount. Pods inherit pull secrets from their ServiceAccount, which centralizes municipal registry auth for many workloads.
Annotating the Namespace with the registry password so every SA inherits pull auth automatically is not a standard Kubernetes inheritance mechanism and stores passwords poorly. Converting the docker-registry Secret into a LimitRange default that injects pull secrets misuses LimitRange. Storing registry credentials in the default ConfigMap kube-root-ca.crt for node downloads corrupts a CA bundle object and does not configure image pulls.
Exam caveat: Pods still need serviceAccountName set to the SA that carries imagePullSecrets if not using default. Operational check: create the docker-registry Secret, add it to the ServiceAccount imagePullSecrets, set Pods to that SA, and confirm images pull without per-Pod pull secret duplication. In CKAD scenarios involving q224, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.