Binding a ClusterRole with a RoleBinding

WHAT THIS TESTS This advanced RBAC question checks whether you know the powerful pattern of referencing a ClusterRole from a namespaced RoleBinding to get reuse without cluster-wide exposure.

A GOOD ANSWER COVERS ClusterRoles define permission sets that are not tied to a namespace. Kubernetes ships several aggregated ones: view (read-only on most namespaced resources), edit, and admin. When you bind a ClusterRole with a ClusterRoleBinding, the subject gets those permissions across every namespace. But when you bind the same ClusterRole with a RoleBinding, the granted permissions are confined to the single namespace where the RoleBinding lives. The ClusterRole supplies the rules; the RoleBinding supplies the namespace scope. This is the standard multi-team pattern: rather than authoring and maintaining identical Role objects in dozens of namespaces, you define the rule set once as a ClusterRole and create a small RoleBinding per namespace, perhaps granting team-a-viewers the view ClusterRole only in team-a's namespace.

COMMON WRONG ANSWERS Saying a RoleBinding to a ClusterRole leaks cluster-wide access is the central error; the binding's scope always wins. Believing you must duplicate Roles in every namespace ignores this reuse mechanism. Confusing this with aggregation rules, which are a separate ClusterRole-composition feature.

LIKELY FOLLOW-UPS What the built-in view, edit, admin, and cluster-admin roles grant. How ClusterRole aggregation works. Why this simplifies onboarding new teams.

ONE CONCRETE EXAMPLE A platform team wants every product squad to read resources only in their own namespace. Instead of N copies of a read Role, they create one RoleBinding per namespace referencing the built-in view ClusterRole and naming that squad's group. Each group sees only its namespace.