CKA Practice Question: Cluster Architecture, Installation and Configuration
You need to grant a ServiceAccount named 'monitor-sa' in namespace 'monitoring' the ability to read Pods and Services across all namespaces. Which TWO resources are needed? (Choose TWO.)
⚠ Common exam trap
A common mix-up: candidates confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide permissions if bound to a ClusterRole, but a RoleBinding only applies to the namespace it is created in, not across all namespaces.
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
✓
ClusterRoleBinding binding the ClusterRole to the ServiceAccount
Option C is correct because reading Pods and Services across all namespaces requires a ClusterRole, which is a cluster-scoped resource whose rules (e.g., apiGroups: [""], resources: ["pods", "services"], verbs: ["get", "list", "watch"]) apply across the entire cluster. Option A is correct because a ClusterRole alone grants nothing; a ClusterRoleBinding must bind that ClusterRole to the ServiceAccount subject (kind: ServiceAccount, name: monitor-sa, namespace: monitoring) to actually confer the permissions cluster-wide. Option B is not needed because token secrets are only for obtaining a long-lived bearer token and are unrelated to RBAC authorization. Option D is wrong because a RoleBinding is namespace-scoped and would have to be created in every namespace individually, which does not satisfy the 'across all namespaces' requirement. Option E is wrong because a Role in the 'monitoring' namespace only grants permissions within that single namespace, not cluster-wide.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
ClusterRoleBinding binding the ClusterRole to the ServiceAccount
Why this is correct
A ClusterRoleBinding is required to apply the permissions defined in a ClusterRole to a subject, such as a ServiceAccount, globally across the entire Kubernetes cluster. This binding mechanism ensures that the ServiceAccount can access resources like pods and services in all namespaces without needing individual namespace-scoped RoleBindings. It is the standard RBAC resource for granting cluster-wide authorization.
- ✗
ServiceAccount token secret
Why it's wrong here
A ServiceAccount token secret is an authentication mechanism used to verify the identity of a pod or client making requests to the API server. It does not define or grant any permissions or access rights itself, which is the role of RBAC resources like Roles and ClusterRoles. Relying on a token secret alone provides no authorization to read pods or services.
- ✓
ClusterRole with rules for pods and services
Why this is correct
A ClusterRole is a non-namespaced RBAC resource that defines a set of permissions, such as "get", "list", and "watch" on pods and services, at the cluster level. To allow a monitoring tool to observe resources across all namespaces, you must first define these permissions within a ClusterRole. This serves as the blueprint of allowed actions before they are bound to a specific identity.
- ✗
RoleBinding in each namespace
Why it's wrong here
A RoleBinding in each namespace fails because RoleBindings are namespace-scoped, meaning they only grant permissions within the specific namespace they are created in. To grant a ServiceAccount the ability to read Pods and Services "across all namespaces", a single ClusterRoleBinding is needed, which applies permissions at the cluster level. This option is tempting as RoleBindings are correctly used for granting namespace-specific access, and would be the appropriate choice if the requirement was to provide permissions only within a defined set of individual namespaces.
- ✗
Role in the 'monitoring' namespace
Why it's wrong here
A Role is strictly a namespaced RBAC resource, meaning any permissions it defines are confined to the specific namespace where the Role is created, such as 'monitoring'. It cannot grant access to pods or services located in other namespaces across the cluster. To monitor resources globally, a cluster-scoped resource like a ClusterRole must be used instead.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 726 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.