CKA Practice Question: Cluster Architecture, Installation and Configuration
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?
⚠ Common exam trap
Many candidates think mounting the ServiceAccount's secret directly (Option C) is still the recommended method, but the CKA exam expects knowledge of the newer, more secure projected token approach introduced in Kubernetes 1.20+.
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
✓
Use a projected service account token with a mount path.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the downward API to inject the token as an environment variable.
Why it's wrong here
The downward API only exposes pod metadata such as the pod name, namespace, labels, annotations, and resource requests or limits; it cannot emit a service account token. Even if a token were injectable this way, placing a sensitive credential in an environment variable would expose it in pod specs, logs, and process listings. Service account tokens must be delivered as files via a volume mount so they can be mounted read-only and safely rotated.
- ✗
Set the token in the pod spec using the 'serviceAccountToken' field.
Why it's wrong here
The Kubernetes pod spec does not define a field named 'serviceAccountToken'; it only has serviceAccountName and automountServiceAccountToken, which control which service account the pod uses and whether the default token is automatically mounted. You cannot specify a literal token value in the pod definition because the API server is responsible for issuing and validating token material. Token injection is always handled by the kubelet through a projected volume or a legacy secret mount, not by a user-supplied spec field.
- ✗
Mount the secret directly using a volume.
Why it's wrong here
Explicitly mounting the service account secret as a volume is technically possible because a legacy service account token is backed by a Secret, but this practice is deprecated and discouraged. Those secret tokens are long-lived, have no built-in expiration or audience restriction, and are not automatically rotated the way projected tokens are, greatly increasing risk if the pod is compromised. Kubernetes now recommends projected serviceAccountToken volumes, which use the TokenRequest API to issue short-lived, audience-scoped tokens that the kubelet can rotate securely.
- ✓
Use a projected service account token with a mount path.
Why this is correct
Use a projected volume with a serviceAccountToken source and set a mountPath—such as /var/run/secrets/kubernetes.io/serviceaccount—to expose a TokenRequest-based token file in the pod. The kubelet requests the token with a configurable audience and expirationSeconds, writes it to the specified path, and automatically rewrites it as expiry approaches, enabling client libraries to reload the credential. This is the recommended approach because it minimizes token lifetime, allows audience restriction, and avoids the security drawbacks of environment variables or unmanaged, long-lived secrets.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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 — 302 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.