A water-billing microservice must pull from a private container registry. What application-side configuration enables successful pulls?
Select an answer to reveal the explanation.
Short Explanation
Private registries are locked doors—your Pod needs a keyring. Stick registry credentials in an imagePullSecret and hang that keyring on the Pod or its ServiceAccount so the kubelet can pull without you SSHing to nodes.
Full Explanation
Water-billing microservices that pull from private registries need credentials available to the kubelet at pull time. The application-side configuration is an imagePullSecret: a kubernetes-registry Secret referenced on the Pod spec or inherited via the Pod’s ServiceAccount. The kubelet uses those credentials when fetching the billing image; without them, pulls fail with authorization errors even if the image name is correct.
Opening etcd to the registry fails conceptually and operationally: etcd stores cluster state, not image layers, and exposing it is a severe security mistake unrelated to pulls. Installing a CSI driver to mount the registry as a block device confuses storage plugins with image distribution. Granting cluster-admin via a ClusterRole does not supply registry passwords and violates least privilege; RBAC does not authenticate to external registries.
Exam caveat: imagePullSecrets are about registry auth for application images, distinct from app runtime Secrets mounted as env/files. CKAD expects the Secret type and the Pod/ServiceAccount reference pattern.
Operational check: create the docker-registry Secret in the namespace, set serviceAccountName or imagePullSecrets on the Pod template, delete a Pod to force pull, and confirm kubectl describe shows successful pull rather than 401/denied.