CKAD Practice Question: Application Environment, Configuration and Security
A ClusterRole named 'pod-reader' allows get, list, and watch on pods. A RoleBinding 'read-pods' in namespace 'default' binds this ClusterRole to user 'jane'. Which statement is true?
⚠ Common exam trap
Many exam-takers assume a ClusterRole always grants cluster-wide permissions, forgetting that a RoleBinding scopes those permissions to a single namespace, while a ClusterRoleBinding is needed for true cluster-wide access.
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
✓
User 'jane' can read pods only in the 'default' namespace
A RoleBinding in a specific namespace binds a ClusterRole to a subject only within that namespace. Since the RoleBinding 'read-pods' is in the 'default' namespace, user 'jane' receives the permissions defined in the 'pod-reader' ClusterRole (get, list, watch on pods) only within the 'default' namespace, not across all namespaces.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
User 'jane' can read pods in all namespaces because ClusterRole is cluster-scoped
Why it's wrong here
A ClusterRole is a cluster-scoped API object, but its permissions only take effect where they are bound. When you attach a ClusterRole to a RoleBinding, the RoleBinding confines those rules to its own namespace. Therefore, Jane can only read pods in the 'default' namespace, not all namespaces, because the binding, not the role, determines the scope of the grant.
- ✗
The RoleBinding must be changed to a ClusterRoleBinding for it to work
Why it's wrong here
No change is required; a RoleBinding is explicitly allowed to reference a ClusterRole. This is the standard way to reuse cluster-wide role definitions while limiting their effect to a single namespace. The existing RoleBinding already grants the ClusterRole's pod read verbs to Jane within the default namespace, so converting it to a ClusterRoleBinding would incorrectly expand her access to every namespace.
- ✗
User 'jane' can read pods and also delete them because ClusterRole gives full access
Why it's wrong here
The ClusterRole's rules only list the verbs get, list, and watch on pods; it does not include delete. Kubernetes RBAC grants exactly the permissions enumerated in a Role or ClusterRole, not implicit full access to the resource. Therefore, Jane cannot delete pods; she has read-only access within the namespace where the binding applies.
- ✓
User 'jane' can read pods only in the 'default' namespace
Why this is correct
A RoleBinding always grants permissions only in the namespace where the binding itself is defined, regardless of whether it references a Role or a ClusterRole. Here, the ClusterRole supplies the pod read rules (get, list, watch), but the RoleBinding limits those rules to the 'default' namespace. As a result, Jane can read pods only in that namespace, not in any other.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 CKAD 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 CKAD exam.