CKS Cluster Hardening Practice Question
A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods, and bound it to a user. The user reports they cannot list pods in namespace 'test', although the same commands work in the 'default' namespace. What is the most likely cause?
⚠ Common exam trap
The CKS exam tests the distinction between ClusterRoleBinding (cluster-wide) and RoleBinding (namespace-scoped). The trap: a ClusterRole grants nothing by itself — the *binding type and its namespace* decide where the permissions apply.
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 ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding
The ClusterRole was bound with a namespace-scoped RoleBinding (created in the 'default' namespace) rather than a cluster-scoped ClusterRoleBinding. A RoleBinding can reference a ClusterRole, but it only grants those permissions inside the RoleBinding's own namespace — which is why access works in 'default' but not in 'test'. Binding the ClusterRole with a ClusterRoleBinding would grant pod access in every namespace. Option A is wrong because a ClusterRoleBinding (not a RoleBinding) is what grants cluster-wide access. Option B is wrong because human users do not need ServiceAccounts. Option D is wrong because the scenario states the ClusterRole includes the 'list' verb.
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 ClusterRole must be bound with a RoleBinding
Why it's wrong here
A ClusterRole does not have to be bound with a RoleBinding; in fact, to grant cluster-wide access, a ClusterRoleBinding is required. Binding a ClusterRole with a RoleBinding would further restrict permissions to a single namespace, which is the opposite of what is needed to allow listing pods in the 'test' namespace.
- ✗
The user needs a ServiceAccount
Why it's wrong here
ServiceAccounts are identities for pods to authenticate to the Kubernetes API, not for human users. Human users typically authenticate via X.509 certificates or OIDC tokens, and RBAC grants them permissions directly without any ServiceAccount. Requiring a ServiceAccount would not change the binding scope and is unrelated to the access problem.
- ✓
The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding
Why this is correct
A ClusterRole bound with a RoleBinding inherits the namespace of that RoleBinding, so the permissions are limited to that namespace only. Because the developer created the RoleBinding in the 'default' namespace instead of using a ClusterRoleBinding, the user's list permission on pods does not extend to the 'test' namespace, causing the forbidden error.
- ✗
The pod-reader ClusterRole is missing 'list' verb
Why it's wrong here
The ClusterRole definition explicitly includes the 'list' verb for pods, so a missing verb is not the cause of the failure. If 'list' were absent, the user would get a validation error when attempting to list pods across all namespaces, but the issue here is specifically the binding scope, not the verb set.
Go deeper
Related to this question
About these practice questions
One of 114 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.