An app ServiceAccount should update only the ConfigMap named billing-ui-config, not every ConfigMap in the namespace. How should the Role be constrained?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: An app ServiceAccount should update only the ConfigMap named billing-ui-config, not every ConfigMap in the namespace. How should the Role be constrained? Correct Answer: Add resourceNames: ["billing-ui-config"] on the ConfigMap rule with update and get verbs Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/cncf/ckad/CKAD-e1-q182.webp)
Short Explanation
resourceNames is the sticky note that says “only this locker,” not the whole row of lockers. Put billing-ui-config on the ConfigMap rule. Subject fields name who is allowed, not which object they may touch.
Full Explanation
When an app ServiceAccount should update only the ConfigMap named billing-ui-config—not every ConfigMap in the namespace—add resourceNames: ["billing-ui-config"] on the ConfigMap rule with update and get verbs (plus patch if the client patches). resourceNames narrows object-level authorization so a civic UI identity cannot alter unrelated ConfigMaps co-located in a shared municipal namespace.
Using a ClusterRole with nonResourceURLs limited to /configmaps/billing-ui-config fails because ConfigMaps are namespaced resources addressed via the resource API, not non-resource URL paths such as /healthz or /metrics. Setting resourceNames under a Role rule for secrets on the theory that ConfigMaps share that field fails—the resources list must explicitly include configmaps. Putting the ConfigMap name in the RoleBinding subject field fails because subjects identify users, groups, or ServiceAccounts rather than target object names.
Exam caveat: list, watch, and create often cannot be constrained with resourceNames the same way get, update, patch, and delete can, so design the verb set carefully. Operational check: apply the constrained Role, RoleBind the ServiceAccount, update billing-ui-config successfully, attempt an update on a different ConfigMap, and confirm the second call returns Forbidden.