KCNA Kubernetes Fundamentals Practice Question
A cluster administrator wants to allow a Pod to access the Kubernetes API to list Pods in its own namespace. Which authentication and authorization mechanism should be used to grant the Pod the necessary permissions?
⚠ Common exam trap
The trap here is thinking that any authentication method works for Pods; ServiceAccounts are specifically designed for this purpose and integrate with RBAC.
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 ServiceAccount, bind it to a Role with a RoleBinding, and use the ServiceAccount token in the Pod.
ServiceAccounts are the standard way to provide an identity for Pods. Combined with RBAC, you can create a Role with the necessary permissions and bind it to the ServiceAccount using a RoleBinding. The Pod automatically receives a token that it can use to authenticate to the API server.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a ServiceAccount, bind it to a Role with a RoleBinding, and use the ServiceAccount token in the Pod.
Why this is correct
ServiceAccounts provide an identity for Pods. A Role defines permissions within a namespace, and a RoleBinding grants those permissions to the ServiceAccount. The Pod can then use the mounted ServiceAccount token to authenticate to the API server and perform actions allowed by the Role.
- ✗
Configure the Pod to use client certificate authentication with a certificate signed by the cluster CA.
Why it's wrong here
Client certificate authentication is typically used for human users or components, not Pods. While it is possible, it requires managing certificates and does not integrate with RBAC as seamlessly as ServiceAccounts. It is not the standard method for Pod-to-API authentication.
- ✗
Set the Pod's hostNetwork to true and use the node's kubelet credentials.
Why it's wrong here
Setting hostNetwork to true allows the Pod to use the node's network namespace, but it does not grant API access. Using kubelet credentials would be a security risk and is not a supported method for Pods to authenticate to the API server. This approach is incorrect and insecure.
- ✗
Use a static token file on the API server and mount it into the Pod.
Why it's wrong here
Static token files are a legacy authentication method and are not recommended. They are not tied to ServiceAccounts and lack the fine-grained authorization integration of RBAC. This approach is insecure and does not follow best practices for Pod authentication.
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
Courseiva writes every KCNA question from scratch — 930 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA practice question is part of Courseiva's free CNCF 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 KCNA exam.