Cross-Namespace ServiceAccount Permissions: ClusterRole & ClusterRoleBinding
An administrator needs to allow a service account 'monitor-sa' in namespace 'monitoring' to read pods across all namespaces. Which RBAC resources should be created?
⚠ Common exam trap
Many exam-takers confuse Role vs ClusterRole scope, thinking a Role can be used with a ClusterRoleBinding or that multiple RoleBindings are the only way to achieve cross-namespace 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
✓
Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa
A ClusterRole is required because the service account needs to read pods across all namespaces, which is a cluster-scoped permission. A ClusterRoleBinding binds that ClusterRole to the service account 'monitor-sa', granting the permissions cluster-wide. This is the correct approach for cross-namespace access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa
Why this is correct
To grant cluster-wide read access to pods for a ServiceAccount, you must define a ClusterRole containing the get, list, and watch verbs for the pods resource. Binding this ClusterRole to the monitor-sa ServiceAccount using a ClusterRoleBinding applies these permissions globally across all namespaces in the cluster.
- ✗
Create a ClusterRole with pod read permissions and a RoleBinding in each namespace
Why it's wrong here
While a RoleBinding can reference a ClusterRole to grant permissions within a single namespace, creating individual RoleBindings in every namespace is highly inefficient and administratively complex. A single ClusterRoleBinding is the correct, native Kubernetes mechanism to grant cluster-wide permissions to a ServiceAccount without duplicating bindings across namespaces.
- ✗
Create a Role in the monitoring namespace and a RoleBinding to monitor-sa
Why it's wrong here
A Role is strictly namespace-scoped and can only grant access to resources within the specific namespace where it is created. Binding a Role in the monitoring namespace to the ServiceAccount will not allow it to read pods in any other namespace, failing the requirement to monitor pods cluster-wide.
- ✗
Create a Role with pod read permissions and a ClusterRoleBinding to monitor-sa
Why it's wrong here
In Kubernetes RBAC, a ClusterRoleBinding's roleRef must point to a ClusterRole. It is syntactically invalid to reference a namespace-scoped Role within a ClusterRoleBinding, and attempting to apply such a configuration will result in an API validation error.
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 |
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 →
Same concept, more angles
1 more way this is tested on CKA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. 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.)
hard- ✓ A.ClusterRoleBinding binding the ClusterRole to the ServiceAccount
- B.ServiceAccount token secret
- ✓ C.ClusterRole with rules for pods and services
- D.RoleBinding in each namespace
- E.Role in the 'monitoring' namespace
Why A: 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.
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.