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.
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 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.