A RoleBinding grants permissions within a specific namespace. While the cluster-admin ClusterRole contains permissions for all actions on all resources cluster-wide, using it in a RoleBinding constrains those powerful permissions to the single namespace where the RoleBinding is created. This grants the subject (e.g., user, service account) complete control over all resources within that namespace, which explicitly includes the ability to modify the namespace object itself (e.g., its labels and annotations).

A: This is incorrect because the cluster-admin role's wildcard permissions ( on resources) include the namespaces resource, thus granting control over the namespace object itself within the binding's scope.

B: This describes the effect of using the cluster-admin role with a ClusterRoleBinding, which grants cluster-wide access. A RoleBinding is strictly namespace-scoped and cannot grant permissions across all namespaces.

D: This describes the default admin role, which is more limited. The admin role specifically disallows write access to resource quotas and the namespace object, unlike the unrestricted cluster-admin role.

1. Kubernetes Documentation

"Using RBAC Authorization": Under the section "Default Roles and Role Bindings

" the cluster-admin role is described: "When used in a RoleBinding

it gives full control over every resource in the RoleBinding's namespace

including the namespace itself." This directly validates answer C. The same section describes the admin role

confirming the description in option D belongs to a different role.

2. Kubernetes Documentation

"Using RBAC Authorization": The distinction between a RoleBinding and ClusterRoleBinding is fundamental. The documentation states

"A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants them cluster-wide." This confirms that a RoleBinding cannot provide the cluster-wide access described in option B.