Three Valid Ways to Authenticate to the Kubernetes API Server
Which TWO of the following are valid methods to authenticate to the Kubernetes API server?
⚠ Common exam trap
Many candidates confuse authorization (RBAC, Node authorization) with authentication, or thinking that Secrets are a credential type presented to the API server, when they are merely storage objects that can hold tokens for later use.
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
✓
Client certificate
Option A (Client certificate) is correct because the Kubernetes API server natively supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O fields become group memberships. Option B (ServiceAccount token) is correct because pods authenticate to the API server using automatically mounted ServiceAccount tokens (JWTs) presented as Bearer tokens, validated by the API server against the service account signing key. Option C (Secrets) is not an authentication method itself — Secrets are objects that may store credentials such as tokens, but they do not authenticate a client to the API server. Option D (RBAC) is an authorization mechanism that determines what an authenticated identity may do, not how it proves its identity. Option E (Node authorization) is an authorization mode (Node authorizer) that governs what kubelets may access, not an authentication method.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Client certificate
Why this is correct
Kubernetes authenticates users via X.509 client certificates presented during the TLS handshake. The certificate's Common Name (CN) is mapped to the username, and organization fields become groups. This is a primary method for external users and components like the kubelet to authenticate to the API server.
- ✓
ServiceAccount token
Why this is correct
ServiceAccount tokens are JSON Web Tokens (JWTs) automatically mounted into pods, used for pod-level authentication to the API server. These bearer tokens are signed by the API server and are validated against the service account's token secret or projected token. They are the standard way for workloads to authenticate with cluster resources.
- ✗
Secrets
Why it's wrong here
Secrets are Kubernetes resources designed to store sensitive data such as credentials, keys, or tokens, but they are not an authentication method themselves. They serve as a data container that authentication mechanisms might reference. Using a Secret does not verify identity; it merely provides the data for a separate process like a client certificate or token.
- ✗
RBAC
Why it's wrong here
Role-Based Access Control (RBAC) is an authorization mechanism that decides what permissions an already-authenticated user or service account has. It evaluates requests against Roles and RoleBindings, but it does not verify the requester's identity. RBAC depends on identity information produced by authentication and therefore cannot be a method of authentication.
- ✗
Node authorization
Why it's wrong here
Node authorization is a special authorization mode that grants kubelets permissions based on their username (e.g., system:node:node1). It is an authorization policy layer, not an authentication method. Node authentication is typically handled separately via client certificates or bootstrap tokens, and node authorization simply applies rules after identity is established.
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
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA 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 CKA exam.