Role versus ClusterRole in RBAC

WHAT THIS TESTS This foundational RBAC question checks that you separate what permissions exist (roles) from who gets them (bindings), and that you know the namespaced versus cluster scope split.

A GOOD ANSWER COVERS A Role is a namespaced object: its rules, lists of apiGroups, resources, and verbs, apply only within the namespace it lives in. A ClusterRole is not namespaced; it can be used to grant access to namespaced resources across all namespaces, to cluster-scoped resources such as nodes, namespaces, and PersistentVolumes, or to non-resource URLs like /healthz. Neither object grants anything by itself; permissions are conferred by a binding. A RoleBinding grants the permissions of a Role (or even a ClusterRole) but only within its own namespace, to a subject which is a User, Group, or ServiceAccount. A ClusterRoleBinding grants a ClusterRole cluster-wide.

COMMON WRONG ANSWERS Saying the binding itself lists verbs and resources is wrong; bindings only reference a role and name subjects. Claiming a Role can grant access to nodes is wrong because nodes are cluster-scoped. Confusing which combinations are legal, for instance trying to bind a Role with a ClusterRoleBinding, which is not allowed.

LIKELY FOLLOW-UPS Can a RoleBinding reference a ClusterRole (yes, to scope reusable roles to one namespace). What subjects are valid. Why ServiceAccounts are namespaced.

ONE CONCRETE EXAMPLE Define a Role pod-reader in team-a with get, list, watch on pods. Create a RoleBinding in team-a referencing it and naming the ServiceAccount ci-bot. That account can now read pods only in team-a, nowhere else.