Pod Authentication to API Server: ServiceAccount
A user needs to deploy a pod that requires access to the Kubernetes API server from within the pod. Which resource should be used to provide authentication credentials automatically?
Quick Answer
The answer is a ServiceAccount, which is the correct resource for providing pod authentication to the API server automatically. When a pod is deployed, Kubernetes mounts a projected volume containing a signed JWT token from the pod’s assigned ServiceAccount, allowing the pod to authenticate against the API server without any manual credential management. This mechanism is essential for in-cluster communication, as the token is automatically refreshed and scoped to the ServiceAccount’s RBAC permissions. On the CKA exam, this concept tests your understanding of secure pod-to-API communication, often appearing in scenarios where you must configure a pod to access cluster resources or troubleshoot authentication failures. A common trap is assuming a user account or static secret is needed, but Kubernetes handles this natively through the ServiceAccount. Memory tip: think “SA for API” — ServiceAccount is the built-in key for pods to talk to the API server securely.
⚠ Common exam trap
Test-takers frequently confuse authorization resources like ClusterRoleBinding with authentication mechanisms, or think that a generic Secret or ConfigMap can serve as an automatic credential provider, when in fact only a ServiceAccount provides the automated token injection and rotation required for in-cluster API access.
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
✓
ServiceAccount
A ServiceAccount is the correct resource because Kubernetes automatically mounts a projected volume containing a JWT token into pods that use the default or a specified ServiceAccount. This token is used by the pod to authenticate against the Kubernetes API server, enabling secure in-cluster communication without manual credential management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
ServiceAccount
Why this is correct
A ServiceAccount supplies pods with an automatically mounted token and CA certificate, giving in-cluster workloads an identity for authenticating to the Kubernetes API server. It satisfies the requirement for automatic credential provisioning without embedding secrets manually.
- ✗
Secret
Why it's wrong here
A Secret stores credentials but does not create or mount them automatically; the pod would need a token manually placed and rotated. Secrets are the right choice for distributing application credentials, TLS certificates or registry logins that are not bound to a ServiceAccount identity.
- ✗
ConfigMap
Why it's wrong here
A ConfigMap stores non-sensitive configuration as key-value pairs, so it cannot supply automatically rotated authentication credentials to a pod. It is tempting because ConfigMaps do mount configuration into containers, and would suit injecting non-confidential settings such as feature flags or log levels. ServiceAccount tokens, not ConfigMaps, provide the API server credentials.
- ✗
ClusterRoleBinding
Why it's wrong here
A ClusterRoleBinding grants permissions to a subject but carries no identity; it cannot supply the pod with a token. It is tempting because it is the cluster-wide counterpart of RoleBinding, and would be correct for granting an existing ServiceAccount API permissions across all namespaces.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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.
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.
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 →
Same concept, more angles
1 more way this is tested on CKA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?
hard- A.Use the downward API to inject the token as an environment variable.
- B.Set the token in the pod spec using the 'serviceAccountToken' field.
- C.Mount the secret directly using a volume.
- ✓ D.Use a projected service account token with a mount path.
Why D: The recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.
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.