mediumMultiple Choice
CKS Practice Question: An administrator runs 'kubectl get…
An administrator runs 'kubectl get clusterrolebindings' and notices a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What security concern does this raise?
⚠ Common exam trap
A common mix-up: candidates think a service account bound to a ClusterRole is limited to its namespace, or that 'cluster-admin' is acceptable for any service account, when the CKS exam specifically tests the principle of least privilege and the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped).
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The service account can now perform any action across all namespaces, which violates least-privilege.
A ClusterRoleBinding grants cluster-wide permissions, and the 'cluster-admin' ClusterRole provides superuser access to perform any action on any resource across all namespaces. Binding this to a service account violates the principle of least privilege because the service account gains unrestricted access to the entire cluster, including sensitive system resources, rather than being limited to only the permissions necessary for its function.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The service account can now perform any action across all namespaces, which violates least-privilege.
Why this is correct
The cluster-admin ClusterRole grants the service account the ability to perform any operation on any resource type in every API group, across all namespaces and cluster-scoped resources. This goes far beyond what a typical workload requires, directly violating the principle of least-privilege and exposing the cluster to significant risk if the SA's token is compromised.
- ✗
The service account can only access resources in the 'default' namespace.
Why it's wrong here
This statement is incorrect because a ClusterRoleBinding is a cluster-scoped resource that binds the service account to the ClusterRole across the entire cluster, not within a single namespace. Unlike a RoleBinding that is limited to one namespace, a ClusterRoleBinding ignores namespace boundaries, so the service account can access resources in every namespace, including kube-system and any newly created ones.
- ✗
No concern; service accounts are allowed to have cluster-admin.
Why it's wrong here
There is no such allowance; service accounts are not inherently trusted and should be granted only the permissions they need. Granting cluster-admin to a service account is a severe security risk because any pod using that SA's token instantly gains full cluster control, and an attacker who compromises that token can delete or alter cluster resources, steal secrets, or pivot to the host nodes.
- ✗
The ClusterRoleBinding should be replaced with a RoleBinding.
Why it's wrong here
Even if a RoleBinding is used, if it binds cluster-admin, it still grants full permissions in that namespace? Actually, cluster-admin in a RoleBinding grants permissions across all resources in that namespace, but still excessive. However, the primary concern is the broad permissions.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.