Service Account Token Path: Accessing the Token in a Pod
A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?
Quick Answer
The answer is /var/run/secrets/kubernetes.io/serviceaccount/token. This is the default mount path where Kubernetes automatically places the service account token as a signed JWT file inside every pod, allowing containerized applications to authenticate against the API server. When a pod’s code attempts to use the Kubernetes API but receives a 403 Forbidden error, it typically means the application is not reading this token file to include in its API requests, so the server rejects the unauthenticated call. On the CKAD exam, this concept tests your understanding of pod-to-API authentication mechanics, often appearing in troubleshooting scenarios where a Role binding exists but the token isn’t being used correctly. A common trap is assuming the token is an environment variable or a configmap—it is not; it is always a file at that specific path. Memory tip: think of the path as “var/run/secrets” because the token is a secret that runs with the pod.
⚠ Common exam trap
CNCF often tests the distinction between the token file, the CA certificate, and the namespace file — candidates confuse the token with the CA cert or think the admin kubeconfig is accessible inside the pod.
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
✓
/var/run/secrets/kubernetes.io/serviceaccount/token
The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
/var/run/secrets/kubernetes.io/serviceaccount/token
Why this is correct
Kubernetes projects the service account token into every pod at a fixed projected volume path. Reading /var/run/secrets/kubernetes.io/serviceaccount/token supplies the bearer token the pod presents to the API server, resolving the 403 caused by missing authentication.
- ✗
/etc/kubernetes/admin.conf
Why it's wrong here
admin.conf is the cluster-admin kubeconfig stored on control plane nodes, not mounted into pods, so the container cannot read it. It is tempting because it does contain client credentials, but it belongs to administrative kubectl access on the host, not workload authentication inside a pod.
- ✗
/var/run/secrets/kubernetes.io/serviceaccount/namespace
Why it's wrong here
The namespace file holds only the pod's namespace string, not a bearer token, so reading it cannot authenticate the API call. It is tempting because the projected service account volume does contain it, but its purpose is informing the client which namespace to target, not supplying credentials.
- ✗
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
Why it's wrong here
The ca.crt file holds the cluster certificate authority bundle used to verify the API server's TLS certificate, not a bearer token, so reading it yields no credential and the 403 persists. The token file is /var/run/secrets/kubernetes.io/serviceaccount/token. The path is tempting because it sits in the same mounted service account directory.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 CKAD
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 pod uses a service account 'my-sa' with a RoleBinding that grants get and list on pods in namespace 'app'. The pod runs a process that calls the Kubernetes API to list pods. However, the API call returns 403. What is the most likely cause?
hard- A.The API server is not running.
- B.The RoleBinding is in the wrong namespace.
- ✓ C.The pod does not have the service account token mounted.
- D.The Role does not include list permission.
Why C: The pod must have the service account token mounted to authenticate to the Kubernetes API server. By default, Kubernetes automatically mounts the service account token into pods via a projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token. If the pod is configured with automountServiceAccountToken: false or the token is not mounted, the API client cannot authenticate, resulting in a 403 Forbidden error even if the RoleBinding grants the correct permissions.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.