CKA Practice Question: Cluster Architecture, Installation and Configuration
A developer created a ClusterRole named 'pod-reader' with rules to get and list pods. They created a ClusterRoleBinding 'read-pods-global' binding this ClusterRole to a service account 'sa-pod-reader' in the 'default' namespace. Which of the following is true about the permissions of this service account?
⚠ Common exam trap
Test-takers frequently confuse ClusterRoleBindings with RoleBindings, mistakenly thinking the service account's permissions are limited to the namespace where the binding or the service account is defined.
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 read pods in all namespaces
ClusterRoleBindings are cluster-scoped, meaning they grant permissions across all namespaces. Since the ClusterRoleBinding 'read-pods-global' binds the 'pod-reader' ClusterRole to the service account 'sa-pod-reader', the service account can get and list pods in every namespace, not just the 'default' namespace.
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 only read pods in the 'default' namespace
Why it's wrong here
This is incorrect because a ClusterRoleBinding is a cluster-scoped authorization object, not a namespaced one. It binds the pod-reader ClusterRole to the service account across every namespace in the cluster, without any namespace selector or restriction. To limit permissions to the 'default' namespace, you would need a RoleBinding (or a Role with namespace-scoped rules) rather than a ClusterRoleBinding.
- ✓
The service account can read pods in all namespaces
Why this is correct
This is correct because a ClusterRoleBinding grants the permissions defined in the ClusterRole to the specified subject (the service account) cluster-wide. The pod-reader ClusterRole includes the 'get' and 'list' verbs on 'pods', and those permissions apply to pods in all namespaces. Therefore, the service account can read pod objects from any namespace, including metadata, specs, and statuses.
- ✗
The service account can only list pods, not get them
Why it's wrong here
This is wrong because the pod-reader ClusterRole specifies both the 'get' and 'list' verbs for pods, not just 'list'. The ClusterRole likely contains rules like resources: ["pods"] and verbs: ["get", "list"], so the service account is authorized to retrieve individual pod details as well as enumerate all pods. Limiting the explanation to only 'list' ignores the 'get' permission that is also explicitly granted.
- ✗
The service account cannot read pods in any namespace
Why it's wrong here
This is incorrect because the ClusterRoleBinding explicitly binds the pod-reader ClusterRole to the service account, thereby granting it effective permissions to read pods. RBAC does not have implicit deny rules beyond 'no binding equals no permission'; once a binding exists, the granted verbs become active. Since the binding is present and valid, the service account can read pods, so the claim that it cannot read in any namespace is false.
Go deeper
Related to this question
About these practice questions
One of 302 original CKA 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 CKA 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 CKA exam.