Cross-Namespace ServiceAccount Permissions: ClusterRole & ClusterRoleBinding
You need to grant a ServiceAccount named 'jenkins' in the 'ci' namespace the ability to list pods in the 'production' namespace. Which RBAC resources should you create?
Quick Answer
The answer is to create a ClusterRole and a ClusterRoleBinding. This is correct because a ServiceAccount named 'jenkins' in the 'ci' namespace needs cross-namespace ServiceAccount permissions to list pods in the 'production' namespace. A ClusterRole grants permissions cluster-wide, not limited to a single namespace, while a ClusterRoleBinding binds that ClusterRole to the ServiceAccount regardless of which namespace the ServiceAccount resides in. In contrast, a Role and RoleBinding are namespace-scoped and cannot grant access across namespaces. On the Certified Kubernetes Administrator CKA exam, this scenario tests your understanding of how RBAC resources handle namespace boundaries—a common trap is reaching for a RoleBinding, which would fail because it cannot cross namespaces. A useful memory tip: think of ClusterRole and ClusterRoleBinding as the "global passport" for a ServiceAccount, allowing it to operate in any namespace, whereas Role and RoleBinding are like a "local ID card" valid only within one namespace.
⚠ Common exam trap
Candidates often think a RoleBinding can bind a Role from another namespace, but RoleBindings are namespace-scoped and can only reference Roles in the same namespace, making a ClusterRole and ClusterRoleBinding necessary for 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 and a ClusterRoleBinding binding the ServiceAccount to the ClusterRole.
A ServiceAccount in one namespace ('ci') needs to list pods in another namespace ('production'). A ClusterRole grants permissions cluster-wide (or across namespaces), and a ClusterRoleBinding binds it to the ServiceAccount, allowing cross-namespace access. Roles and RoleBindings are namespace-scoped and cannot grant permissions across 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.
- ✗
Create a ClusterRole in the 'production' namespace and a RoleBinding in the 'ci' namespace.
Why it's wrong here
ClusterRoles are not namespaced; you cannot create a ClusterRole inside a namespace. Also RoleBinding cannot bind a ClusterRole to grant permissions in a different namespace.
- ✗
Create a Role in the 'production' namespace and a RoleBinding in the 'ci' namespace referencing the Role.
Why it's wrong here
A RoleBinding cannot reference a Role in a different namespace; RoleBindings are namespaced and must reference a Role in the same namespace.
- ✗
Create a Role in the 'ci' namespace and a RoleBinding binding the ServiceAccount to the Role.
Why it's wrong here
A Role is namespaced to 'ci' and cannot grant permissions in 'production'.
- ✓
Create a ClusterRole and a ClusterRoleBinding binding the ServiceAccount to the ClusterRole.
Why this is correct
A ClusterRole can define permissions for pods in any namespace, and a ClusterRoleBinding grants those permissions cluster-wide, including to the ServiceAccount.
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
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways 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: A is correct because a ClusterRoleBinding grants cluster-scoped permissions to a subject (like a ServiceAccount) across all namespaces. Since the ServiceAccount 'monitor-sa' needs to read Pods and Services in every namespace, a ClusterRoleBinding is the appropriate resource to bind a ClusterRole to the ServiceAccount, avoiding the need for per-namespace RoleBindings.
Variation 2. 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?
medium- ✓ A.Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa
- B.Create a ClusterRole with pod read permissions and a RoleBinding in each namespace
- C.Create a Role in the monitoring namespace and a RoleBinding to monitor-sa
- D.Create a Role with pod read permissions and a ClusterRoleBinding to monitor-sa
Why A: 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.
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.