KCSA Kubernetes Security Fundamentals Practice Question
You want to ensure that a newly created Role in namespace 'finance' cannot be modified or deleted by regular developers who have edit permissions. Which RBAC feature or design prevents unauthorized privilege escalation through Role manipulation?
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
✓
The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.
Kubernetes has built-in authorization checks (RBAC privilege escalation prevention) that prevent users from creating or editing roles/rolebindings with permissions they do not themselves possess.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enabling Pod Security Standards on the finance namespace.
Why it's wrong here
Pod Security Standards govern pod specs, not RBAC roles.
- ✗
Setting the Role resource to immutable via 'immutable: true'.
Why it's wrong here
While Secrets and ConfigMaps support the immutable field, Roles do not have an immutable field.
- ✗
A mandatory MutatingWebhookConfiguration that strips administrative verbs.
Why it's wrong here
Privilege escalation prevention is built directly into the Kubernetes RBAC authorizer, not requiring custom webhooks.
- ✓
The API server's built-in privilege escalation prevention check, which blocks users from granting permissions they do not hold.
Why this is correct
Users cannot assign permissions via Roles or RoleBindings unless they already possess those exact permissions themselves.
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
This KCSA question is part of Courseiva's 320-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 August 2026 · checked against the official CNCF / Linux Foundation exam blueprint
This KCSA practice question is part of Courseiva's free CNCF / Linux Foundation 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 KCSA exam.