CKS Minimize Microservice Vulnerabilities Practice Question
You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?
⚠ Common exam trap
This exam often tests the misconception that the default service account token is secure because it is automatically mounted, but the trap is that it is a long-lived token with no expiration, whereas the projected volume with `expirationSeconds` provides a short-lived, automatically rotated token that aligns with security best practices.
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 volume with 'serviceAccountToken' and set 'expirationSeconds'
Using a projected volume with `serviceAccountToken` and setting `expirationSeconds` allows you to explicitly control the token's lifetime, ensuring it is short-lived and automatically rotated. This is the most secure approach as it prevents the use of long-lived tokens that could be compromised. The default service account token is a long-lived token with no expiration, which violates the principle of minimizing credential exposure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount
Why it's wrong here
The default mount places a legacy long-lived token at the well-known path, exactly the behaviour the scenario seeks to eliminate. It is the automatic fallback when no projected volume is defined, but it offers no expiry or audience binding, so it fails the requirement for short-lived, bound tokens.
- ✓
Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'
Why this is correct
A projected volume with a serviceAccountToken source and expirationSeconds issues a short-lived, audience-bound token that the kubelet rotates automatically, satisfying the requirement that the pod not rely on a long-lived legacy token. Plain secret mounts or automountServiceAccountToken alone cannot enforce expiry.
- ✗
Set automountServiceAccountToken: false and manually mount a Secret containing a token
Why it's wrong here
Disabling automount and mounting a Secret yields a static token with no expiry or audience claim, and Secrets are not rotated by the kubelet. Secrets suit distributing credentials manually, but the projected volume with a bound service account token is what provides automatic expiry and audience restriction.
- ✗
Use a ConfigMap to inject the token
Why it's wrong here
A ConfigMap stores configuration data, not credentials; injecting a token this way creates a static, non-expiring secret with no API-server binding or audience claim. ConfigMaps suit non-sensitive settings, but projected service account tokens with bound audiences and expiry are what the scenario requires.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS 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 CKS exam.