mediumMultiple Choice
CAS-004 Practice Question: Refer to the exhibit
Exhibit
# kubectl describe pod my-app-pod
Name: my-app-pod
Namespace: default
Node: worker-node-1/192.168.1.10
Start Time: Tue, 15 Aug 2023 14:30:00 UTC
Labels: app=my-app
Annotations: none
Status: Running
Containers:
my-app-container:
Container ID: docker://abc123
Image: myregistry.com/my-app:v1.0
Image ID: docker-pullable://myregistry.com/my-app@sha256:xyz
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Tue, 15 Aug 2023 14:30:05 UTC
Ready: True
Restart Count: 0
Environment:
DB_PASSWORD: <set to the key 'db-password' in secret 'db-secret'> Optional: false
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-abc (ro)Refer to the exhibit. A security analyst notices that the pod is running with a service account token mounted. Which security best practice should be implemented to reduce the risk of token theft in container environments?
⚠ Common exam trap
CAS-005 often tests the misconception that storing tokens in secrets or using different runtimes improves security, but the most direct mitigation is to not mount the token at all.
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
✓
Set automountServiceAccountToken to false in the pod spec.
Setting automountServiceAccountToken to false in the pod spec prevents the default service account token from being automatically mounted into the pod's filesystem. This reduces the risk of token theft because the token is not present unless explicitly mounted. This is a Kubernetes security best practice for pods that do not need to interact with the Kubernetes API.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the token in a Kubernetes secret and mount it.
Why it's wrong here
Mounting a long-lived token via a Kubernetes secret still exposes a static credential to any container compromise, so theft risk is unchanged. Secrets suit distributing configuration data or certificates, not replacing short-lived, audience-bound projected service account tokens.
- ✗
Use a different container runtime.
Why it's wrong here
The runtime (containerd, CRI-O) executes containers; it does not govern token projection or mounting, so swapping it leaves the mounted credential exposed. Runtime selection matters for isolation hardening such as gVisor or Kata, not for service account token exposure.
- ✗
Disable the service account for the pod.
Why it's wrong here
Disabling the service account removes all pod identity, breaking legitimate API authentication rather than reducing theft risk. It is tempting because unused credentials should be eliminated, which is correct when a pod genuinely needs no cluster API access at all.
- ✓
Set automountServiceAccountToken to false in the pod spec.
Why this is correct
Setting automountServiceAccountToken to false stops Kubernetes projecting the service account token into the pod's filesystem, so a compromised container cannot read or exfiltrate it. This directly satisfies the requirement to reduce token theft risk by removing the credential from the pod entirely.
Go deeper
Related to this question
About these practice questions
This CAS-005 question is part of Courseiva's 973-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA 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 CAS-005 exam.