CCSP Cloud Platform and Infrastructure Security Practice Question
A security team implements Kubernetes RBAC. They want to ensure that a service account can only create pods in the 'dev' namespace. Which RBAC resource should they use?
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
✓
Role and RoleBinding in the 'dev' namespace
RBAC uses Role and RoleBinding for namespace-scoped permissions. ClusterRole and ClusterRoleBinding are cluster-scoped. A Role with permissions to create pods in the 'dev' namespace, bound via RoleBinding, achieves the goal.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
ClusterRole and ClusterRoleBinding
Why it's wrong here
ClusterRole and ClusterRoleBinding grant permissions cluster-wide, so the service account could create pods in every namespace, not just 'dev'. It is tempting because ClusterRoles are required for cluster-scoped resources such as nodes or persistent volumes, and would be correct had the requirement spanned all namespaces.
- ✓
Role and RoleBinding in the 'dev' namespace
Why this is correct
A Role defines permissions within a single namespace, and a RoleBinding grants those permissions to the service account only in that namespace. This satisfies the stem's constraint that pod creation is limited to the 'dev' namespace, unlike ClusterRole and ClusterRoleBinding.
- ✗
PodSecurityPolicy (deprecated)
Why it's wrong here
PodSecurityPolicy governs pod security attributes — privileged mode, host mounts, capabilities — not which namespace a service account may act in, and it was removed in Kubernetes 1.25. It is tempting because it constrains pod creation, and would be correct for restricting privileged or host-network pods rather than namespace scope.
- ✗
NetworkPolicy
Why it's wrong here
NetworkPolicy filters ingress and egress traffic between pods and namespaces at layer 3/4; it never authorises API verbs, so pod creation in 'dev' remains unrestricted. It is tempting because it also references namespaces, and would be correct for isolating 'dev' pod traffic from other namespaces, not for RBAC authorisation.
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 CCSP question from scratch — 934 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CCSP practice question is part of Courseiva's free ISC2 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 CCSP exam.