A Role grants get/list on ConfigMaps in maps. How is ServiceAccount map-reader authorized to use that Role?
Select an answer to reveal the explanation.
Short Explanation
Roles list verbs; RoleBindings name who gets them. Put kind: ServiceAccount, name map-reader, and its namespace in the binding subjects. That's how the SA actually receives the ConfigMap read rights.
Full Explanation
A Role that grants get/list on ConfigMaps in maps authorizes ServiceAccount map-reader only when a RoleBinding's subjects include kind ServiceAccount with name map-reader and the correct namespace. RoleBindings connect identities to Roles; the Role's rules alone do not name ServiceAccounts as verbs or subjects. Municipal RBAC always needs both the Role and the binding.
Patching the Role's rules to include the ServiceAccount name as an API verb fails—verbs are get/list/create/etc., not identity names. Adding map-reader to the Role's metadata.ownerReferences so permissions inherit automatically does not grant RBAC. Labeling the ServiceAccount rbac.authorization.k8s.io/aggregate-to-admin true without a RoleBinding misuses aggregation labels and does not bind the Role.
Exam caveat: RoleBinding namespace must match where the Role applies; subject namespace for ServiceAccounts must identify the SA's namespace. Operational check: create the RoleBinding with subject ServiceAccount map-reader, test auth can-i get configmaps --as=system:serviceaccount:maps:map-reader -n maps, and confirm access works only as intended. In CKAD scenarios involving q225, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.