Namespace-Scoped ServiceAccount Permissions: Role & RoleBinding
A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?
Quick Answer
The correct answer is to create a Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, then a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount. This configuration is appropriate because namespace-scoped ServiceAccount permissions require a Role to define what actions are allowed on specific resources, and a RoleBinding to attach that Role to a ServiceAccount within the same namespace. On the Certified Kubernetes Administrator CKA exam, this scenario tests your understanding of Kubernetes RBAC scoping—a common trap is using a ClusterRole and ClusterRoleBinding, which would grant permissions cluster-wide, violating least privilege. Instead, remember that Role and RoleBinding are namespace-scoped, while ClusterRole and ClusterRoleBinding are cluster-scoped. A helpful memory tip: "Role and RoleBinding stay in their namespace—like a guard at a specific building door, not the whole city."
⚠ Common exam trap
It's easy for candidates to confuse the scope of Roles versus ClusterRoles, mistakenly using a ClusterRole when a namespace-scoped Role is sufficient, or creating a Role in the wrong namespace and assuming a RoleBinding can bridge 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
✓
Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa
A Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.
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 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa
Why it's wrong here
A ClusterRole with a ClusterRoleBinding grants pod list rights across every namespace, exceeding the least-privilege requirement for 'monitoring' alone. The tempting appeal is reuse of a single cluster-scoped object, but a namespaced Role plus RoleBinding confines access. ClusterRoleBinding is correct only when cluster-wide pod visibility is genuinely required.
- ✗
Add the ServiceAccount to the cluster-admin group
Why it's wrong here
cluster-admin grants full control of the entire cluster, far beyond listing pods in one namespace, and violates least privilege. It is tempting because it guarantees the permission works without crafting rules. A namespaced Role with 'get' and 'list' on pods, bound via RoleBinding in 'monitoring', satisfies the requirement precisely.
- ✗
Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa
Why it's wrong here
A Role in 'default' cannot authorise actions in 'monitoring'; RoleBindings only grant permissions defined in a Role within the same namespace. The tempting logic is that binding in 'monitoring' redirects the grant, but Kubernetes does not resolve rules across namespaces. Both Role and RoleBinding must reside in 'monitoring'.
- ✓
Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa
Why this is correct
A namespaced Role scoped to 'monitoring' grants only the 'get' and 'list' verbs on pods, satisfying least privilege. Binding it with a RoleBinding in the same namespace restricts monitor-sa's permissions to that namespace, which is exactly the constraint the stem requires.
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
Courseiva writes every CKA question from scratch — 726 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 want to grant a user read-only access to all pods in the 'development' namespace. Which RBAC resource should you create?
medium- A.ClusterRoleBinding with get, list, watch on pods
- ✓ B.Role in the development namespace with get, list, watch on pods
- C.ClusterRole with get, list, watch on pods
- D.RoleBinding referencing a ClusterRole that has get, list, watch on pods
Why B: A Role in the 'development' namespace with get, list, watch on pods is correct because RBAC Roles are namespace-scoped and grant permissions only within that namespace. Since the requirement is read-only access to pods in a specific namespace, a Role is the appropriate resource to define these permissions.
Variation 2. You need to create a RoleBinding that grants a user access to read Pods in the 'dev' namespace. Which YAML manifest is correct?
medium- A.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader
- B.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader
- C.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader
- ✓ D.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-reader
Why D: It defines a RoleBinding in the 'dev' namespace that binds a User named 'dev-user' to a Role named 'pod-reader'. This grants the user read access to Pods within that specific namespace, which is exactly what the question requires. RoleBindings are namespace-scoped and must specify the target namespace in metadata.
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.