CKS Minimize Microservice Vulnerabilities Practice Question
Which of the following is the best practice for injecting secrets into a pod?
⚠ Common exam trap
Kubernetes often tests the misconception that environment variables are a safe way to inject secrets because they are 'in-memory,' but the trap here is that environment variables are visible in the process environment, can be leaked via `/proc`, and cannot be rotated without restarting the pod, making volume mounts the only secure and dynamic option.
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
✓
Injecting via volume mounts
Mounting secrets as volumes ensures that secret data is stored in the pod's filesystem as files, which are created in a tmpfs in-memory filesystem (ram-backed) and never written to disk. This approach also allows for automatic rotation of secret values when the Secret object is updated, without requiring a pod restart, and avoids exposing secrets in process listings or container logs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Storing secrets in container image layers
Why it's wrong here
Storing secrets in container image layers embeds them into the immutable, shareable snapshot of the filesystem. Any user with registry pull access can extract the secret by inspecting the image history or unpacking the layers; additionally, layer caching and distribution replications make the secret persistently available across many systems, greatly expanding the attack surface.
- ✗
Using environment variables
Why it's wrong here
Using environment variables to inject secrets is risky because these values are visible from inside the pod via /proc/1/environ and commonly appear in logs, error traces, and debugging output. They are passed to every child process and can be inadvertently exposed by third-party libraries or shell commands that dump the process environment.
- ✗
Using ConfigMap for secrets
Why it's wrong here
ConfigMap is designed for non-confidential configuration data and stores values in plaintext in etcd, accessible via the Kubernetes API to anyone with RBAC read access. Although etcd can be encrypted at rest, ConfigMaps lack purpose-built secret protections like rotation, access auditing, and encryption in transit, making them a poor choice for sensitive credentials.
- ✓
Injecting via volume mounts
Why this is correct
Mounting secrets as files in a volume is safer because the sensitive data appears only as file contents at the specified mount path, not in environment variables. It allows per-pod filesystem permissions, like read-only and mode settings, and is easier to rotate, as a change to the Secret object will eventually update the mounted file without restarting the container.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-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 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.