Why should powerful Roles not be bound to the namespace default ServiceAccount?
Select an answer to reveal the explanation.
Short Explanation
Default SA is the shared hallway badge—lots of Pods wear it if you don't pick another. Hang powerful Roles on it and you've handed those rights to anyone still on default. Use dedicated ServiceAccounts for privileged apps instead.
Full Explanation
Powerful Roles should not be bound to the namespace default ServiceAccount because many Pods inherit the default ServiceAccount unless overridden, so broad privileges would apply more widely than intended. Municipal namespaces often run assorted workloads on default accidentally; binding admin-like Roles there spreads power to every forgetful Pod template.
Claiming the default ServiceAccount cannot be referenced by Pods so bindings never take effect fails—default is the implicit ServiceAccount for Pods that omit serviceAccountName. Claiming RoleBindings to default are rejected by the API server in every Kubernetes version is false. Claiming the default ServiceAccount only works with ClusterRoles and ignores RoleBindings by design invents a restriction that does not exist.
Exam caveat: create dedicated ServiceAccounts per app and bind Roles only to those identities. Operational check: audit RoleBindings subjects for default, move powerful bindings to named ServiceAccounts, set serviceAccountName explicitly on Deployments, and leave default unbound to high privilege. In CKAD scenarios involving q222, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.