Pod API Authentication Token Methods
Which THREE are valid methods to provide authentication to the Kubernetes API server? (Select three.)
⚠ Common exam trap
Test-takers frequently confuse SSH keys (used for node-level access) with client certificates or tokens used for API server authentication, or mistakenly think username/password is still a supported method in current Kubernetes versions.
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 certificates
Option B (Client certificates) is correct because the Kubernetes API server supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O becomes the group. Option C (ServiceAccount bearer tokens) is correct because pods authenticate to the API server using ServiceAccount tokens mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, which are validated by the API server's service account token authenticator. Option D (Static token file) is correct because the API server can be configured with --token-auth-file to authenticate requests bearing a bearer token listed in a CSV token file. Option A (Username and password) is not a valid API server authentication method — basic auth was removed in Kubernetes 1.19, so it no longer applies. Option E (SSH keys) is not valid because SSH keys are used for secure shell access to nodes, not for authenticating to the Kubernetes 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.
- ✗
Username and password
Why it's wrong here
Username and password authentication was historically supported via the --basic-auth-file flag, but it has been deprecated and removed from Kubernetes. The API server would parse a CSV file with password, username, and optional UID/GID, sending plaintext credentials over the wire unless TLS was used. This method is insecure because passwords are stored in plaintext and never hashed, and modern Kubernetes therefore relies on token-based or certificate-based authentication.
- ✓
Client certificates
Why this is correct
Client certificate authentication uses X.509 certificates signed by a certificate authority that the API server trusts (configured via --client-ca-file). When a user presents a certificate, the API server validates the signature, expiration, and key usage, and then extracts the Common Name as the username and Organization as the groups. This method is cryptographically strong, supports revocation through CRLs, and is one of the primary ways administrators and advanced users authenticate to the cluster.
- ✓
ServiceAccount bearer tokens
Why this is correct
ServiceAccount bearer tokens are JSON Web Tokens (JWTs) signed by the API server's private key (--service-account-key-file), automatically mounted into pods. These tokens authenticate the pod's service account to the API server, with the service account name and namespace encoded in the token claims. They are designed for in-cluster pod-to-API communication, have configurable audiences and expiration, and are verified using the public signing key by the API server's token authenticator.
- ✓
Static token file
Why this is correct
Static token file authentication uses a CSV file specified with --token-auth-file, containing token, username, and optional group information. The API server reads this file at startup and issues bearer tokens that are matched against the static list for authentication. This method is simple and useful for inanimate machine users, but it lacks rotation, expiration, and storage security since tokens are stored in plaintext in the file.
- ✗
SSH keys
Why it's wrong here
SSH keys authenticate an entity to a remote host via the SSH protocol, establishing an encrypted shell session. The Kubernetes API server has no mechanism to validate SSH public keys or signatures as part of its authentication chain; it only accepts HTTP-based authentication methods. SSH keys are relevant for node-level access through tools like ssh or kubectl exec with SSH, but they do not authenticate a user to the Kubernetes API.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
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
Courseiva writes every CKA question from scratch — 726 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 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.