EX280 User And RBAC Management Practice Question
An OpenShift administrator needs to restrict developers so they cannot delete any PersistentVolumeClaims in the 'finance-prod' namespace, even though they have the 'admin' role. How can this override be achieved?
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 custom Role that omits the 'delete' verb for persistentvolumeclaims, remove the 'admin' role binding, and bind this custom Role instead.
RBAC in Kubernetes/OpenShift is strictly additive. To deny a specific action like deletion while granting admin, a custom role and binding cannot deny by default unless using specialized admission webhooks or custom authorization webhooks. Wait, Kubernetes RBAC does not support explicit denies. However, you can create a custom role without delete verbs and bind that, but if they have 'admin', they keep admin unless you remove it. To truly restrict specific verbs when using built-in roles, you cannot override unless you modify the role or use a custom authorization webhook/admission control. Let's check alternative mechanisms: Exclusion is handled by custom RBAC roles instead of 'admin', or using admission webhooks. Since standard RBAC is additive, a user cannot have 'admin' and simultaneously be denied a subset via RBAC alone without replacing the role. Let's frame the question around replacing 'admin' with a custom role that omits delete verbs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a negative annotation to the user's account object.
Why it's wrong here
User annotations do not control API access permissions.
- ✗
Configure a LimitRange object with delete blocks.
Why it's wrong here
LimitRanges manage resource consumption sizes, not API action verbs.
- ✗
Create a DenyRoleBinding specifying delete verb exclusion for persistentvolumeclaims.
Why it's wrong here
Kubernetes RBAC does not support Deny RoleBindings or explicit denial rules.
- ✓
Create a custom Role that omits the 'delete' verb for persistentvolumeclaims, remove the 'admin' role binding, and bind this custom Role instead.
Why this is correct
Because RBAC is purely additive, you cannot deny an action if a user holds a role ('admin') that grants it; you must replace the role with a restricted custom role.
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 EX280 question is part of Courseiva's 509-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 Red Hat exam blueprint
This EX280 practice question is part of Courseiva's free Red Hat 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 EX280 exam.