KCSA Kubernetes Security Fundamentals Practice Question
You need to ensure that a Secret containing database credentials cannot be read by anyone except the database application controller, even if they have broad RBAC read permissions in the namespace. Which feature should you consider?
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
✓
Store the credentials in an external secrets manager and use an Operator to inject them directly into pod environment variables, avoiding the creation of Kubernetes Secret objects entirely.
Standard Kubernetes RBAC is resource-based and does not support cell-level or secret-value level restrictions natively within a namespace once read access to secrets is granted. However, migrating to an external secrets manager or using advanced admission control can restrict access. Within native Kubernetes, RBAC allows reading secrets if 'get' or 'list' is granted on 'secrets'. To strictly isolate secrets, external secret operators injecting secrets via environment variables or volume mounts without granting direct secret API access is standard practice.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable the ValidatingAdmissionPolicy to inspect the user's decryption key.
Why it's wrong here
Admission policies control resource creation/updates, not subsequent read requests for existing secrets.
- ✓
Store the credentials in an external secrets manager and use an Operator to inject them directly into pod environment variables, avoiding the creation of Kubernetes Secret objects entirely.
Why this is correct
Avoiding Kubernetes Secret objects eliminates the risk of users with namespace Secret read permissions accessing the credentials.
- ✗
Set the secret data encoding to AES-256 within the manifest metadata.
Why it's wrong here
Secret data must be base64 encoded, and custom metadata fields do not alter RBAC or read capabilities.
- ✗
Apply a Role restricting Secret viewing by adding a label selector to the RoleBinding.
Why it's wrong here
RoleBindings do not support label selectors to restrict access to individual secret objects based on their labels.
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 319-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.