CAS-004 Security Architecture Practice Question
A security analyst is reviewing a Kubernetes cluster and wants to ensure that only authorized users can create or modify pods. Which Kubernetes object should be configured to enforce this?
⚠ Common exam trap
CAS-005 often tests the confusion between authorization (RBAC) and admission control or pod security, tricking candidates into choosing admission controllers when the question is about who can perform API actions.
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
✓
RBAC
Kubernetes RBAC (Role-Based Access Control) uses Roles/ClusterRoles bound to users, groups, or service accounts via RoleBindings/ClusterRoleBindings to authorize actions like create or modify on pods. Configuring RBAC with verbs such as create, update, and patch on the pods resource enforces exactly who can manipulate pods.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Admission controllers
Why it's wrong here
Admission controllers intercept API requests to enforce policy, but they are cluster control-plane components, not the Kubernetes object an administrator configures to authorise which users may create or modify pods. They are tempting because they do enforce pod admission rules, and would be correct for validating or mutating pod specifications at creation time.
- ✗
Pod security policies
Why it's wrong here
Pod security policies governed pod security context settings such as privileged mode and host namespaces, not which users may create or modify pods. They are tempting because they restrict pod creation, and would be correct for enforcing cluster-wide pod security standards rather than user authorisation.
- ✓
RBAC
Why this is correct
RBAC binds Roles or ClusterRoles, which define verbs such as create and modify on pods, to users or groups via RoleBindings. This satisfies the authorisation constraint by restricting pod write operations to explicitly granted subjects.
- ✗
Network policies
Why it's wrong here
Network policies control pod-to-pod traffic flows at Layers 3 and 4; they do not govern who may create or modify pod objects. They are tempting because they are pod-scoped Kubernetes objects, and would be the correct choice when restricting which pods can communicate with each other or with external endpoints.
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
This CAS-005 question is part of Courseiva's 973-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA 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 CAS-005 exam.