mediumMultiple Choice
CKS Practice Question: Restrict a service account to only be able to…
An administrator wants to restrict a service account to only be able to create pods in the 'development' namespace. Which RBAC configuration should be used?
⚠ Common exam trap
CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly choose a ClusterRole with a RoleBinding (Option D) thinking it restricts to a namespace, but the ClusterRole itself may grant broader permissions or include cluster-scoped resources, violating the principle of least privilege.
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 the 'development' namespace and a RoleBinding that binds the service account to that Role.
A Role is namespace-scoped and can only grant permissions within the namespace where it is created. By creating a Role in the 'development' namespace and binding the service account to it via a RoleBinding, the service account is restricted to creating pods only in that namespace, as required.
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 Role in the default namespace and a RoleBinding that binds the service account to that Role.
Why it's wrong here
Creating a Role and RoleBinding in the default namespace scopes the permissions to the default namespace, not the development namespace. Since RoleBindings only apply to the namespace in which they are created, a service account used in development would not receive permissions there, leaving it unable to perform the required actions. The Role must live in the same namespace as the resources the service account needs to access.
- ✓
Create a Role in the 'development' namespace and a RoleBinding that binds the service account to that Role.
Why this is correct
Roles and RoleBindings are namespaced resources, so creating both in the 'development' namespace limits the service account's permissions to only the resources in that namespace. This directly satisfies the requirement of restricting the service account to the intended namespace, and it follows the principle of least privilege by avoiding any cluster-wide or cross-namespace permissions.
- ✗
Create a ClusterRole and a ClusterRoleBinding that binds the service account to that ClusterRole.
Why it's wrong here
A ClusterRoleBinding binds a ClusterRole across all namespaces, granting the service account permissions cluster-wide. This violates the restriction to the development namespace, as the service account would be able to perform the same actions in every namespace. Even if the ClusterRole contains specific rules, the binding itself is cluster-scoped, which is too broad for a single-namespace restriction.
- ✗
Create a ClusterRole and a RoleBinding in the 'development' namespace.
Why it's wrong here
Although a RoleBinding in the development namespace can reference a ClusterRole, this approach creates a cluster-scoped ClusterRole when a namespaced Role would be more appropriate and secure. Using a ClusterRole widens the scope of where the permissions can be bound and risks accidental reuse or over-permissioning across namespaces. The correct practice is to define a Role directly in the development namespace to keep the permission boundary explicit and tightly scoped.
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 845 original CKS 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 CKS 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 CKS exam.