CKA Practice Question: Cluster Architecture, Installation and Configuration
You have a service account named 'my-sa' in the 'default' namespace. You want to mount its token into a pod automatically. Which field in the pod spec achieves this?
⚠ Common exam trap
Many exam-takers confuse `spec.serviceAccountName` with the deprecated `spec.serviceAccount` field, or think that `spec.automountServiceAccountToken` alone is sufficient to mount a specific service account's token, when it only controls the mounting behavior for the default service account.
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
✓
spec.serviceAccountName
Setting `spec.serviceAccountName` to 'my-sa' in the pod spec automatically mounts the service account token as a volume at `/var/run/secrets/kubernetes.io/serviceaccount/`. This is the standard way to associate a service account with a pod, and Kubernetes automatically handles token projection and mounting for that service account.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
spec.serviceAccountName
Why this is correct
The `spec.serviceAccountName` field within a Pod's definition is the precise mechanism for explicitly associating a Pod with a specific Kubernetes ServiceAccount. When this field is set, Kubernetes ensures that the specified ServiceAccount's token is automatically mounted into the Pod at `/var/run/secrets/kubernetes.io/serviceaccount`, providing the Pod with the necessary credentials to interact with the Kubernetes API server. This direct linkage is crucial for granting Pods specific permissions defined by role bindings to that ServiceAccount.
- ✗
spec.serviceAccount
Why it's wrong here
The `spec.serviceAccount` field is indeed deprecated and should not be used in modern Kubernetes manifests. While it historically served a similar purpose to `spec.serviceAccountName` by specifying the ServiceAccount for a Pod, its usage is now discouraged to prevent confusion and ensure compatibility with current API versions. Relying on deprecated fields can lead to unexpected behavior or manifest validation failures in future Kubernetes releases, making `spec.serviceAccountName` the only correct and supported option.
- ✗
spec.containers[].env[].valueFrom.secretKeyRef
Why it's wrong here
This configuration path is specifically designed for injecting individual key-value pairs from a Kubernetes Secret resource directly into a container's environment variables. It allows applications to consume sensitive configuration data without hardcoding it within the image. However, ServiceAccount tokens are typically mounted as files within a volume, not exposed as environment variables, and they originate from the ServiceAccount resource itself, not a user-defined Secret. Therefore, this mechanism is entirely unrelated to managing ServiceAccount tokens.
- ✗
spec.automountServiceAccountToken
Why it's wrong here
The `spec.automountServiceAccountToken` field is a boolean flag that controls whether the ServiceAccount token, determined by `spec.serviceAccountName` (or the default ServiceAccount if not specified), should be automatically mounted into the Pod's filesystem. Setting it to `false` prevents the token from being mounted, which is a security best practice for Pods that do not require API access. However, this field only dictates the *behavior* of mounting; it does not specify *which* ServiceAccount's token to use.
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
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.