A Pod must call cloud APIs using permissions bound to ServiceAccount geo-reader instead of the namespace default. What Pod field assigns that identity?
Select an answer to reveal the explanation.
Short Explanation
serviceAccountName is the badge clipped to the Pod—set it to geo-reader and the workload runs as that SA. Labels and imagePullSecrets don't swap the API identity by themselves. Default SA is what you get if you leave it blank.
Full Explanation
A Pod that must call cloud APIs using permissions bound to ServiceAccount geo-reader instead of the namespace default should set spec.serviceAccountName to geo-reader on the Pod or Pod template. That field selects which ServiceAccount token is mounted for in-cluster or projected identity use by municipal geo services.
Setting metadata.generateName to geo-reader does not assign a ServiceAccount; generateName only influences generated object names. Listing geo-reader under spec.imagePullSecrets changes pull credentials, not the runtime API identity. Adding a label kubernetes.io/serviceaccount=geo-reader without changing identity fields is cosmetic and does not bind the Pod to that ServiceAccount.
Exam caveat: the ServiceAccount must exist in the same namespace before Pods that reference it will start cleanly. Operational check: create ServiceAccount geo-reader, set serviceAccountName on the Pod template, deploy, and confirm the mounted token identity matches geo-reader in the Pod spec. In CKAD scenarios involving q220, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings. Keep municipal change tickets linked to the exact manifest diff so operators can audit why q220 was adjusted.