CKS Minimize Microservice Vulnerabilities Practice Question
A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?
⚠ Common exam trap
CNCF often tests the misconception that environment variables from Secrets are equally secure as volume mounts, but the trap is that environment variables are more exposed to runtime leaks and cannot be rotated without pod restart, whereas volume mounts offer better isolation and live update capabilities.
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
✓
Store the API key in a Kubernetes Secret and mount it as a volume inside the container
Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.
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 API key in a ConfigMap and expose it as an environment variable
Why it's wrong here
ConfigMaps are for non-sensitive configuration data, not secrets.
- ✗
Hardcode the API key in the container image
Why it's wrong here
Hardcoding secrets in images is insecure and makes rotation impossible without rebuilding.
- ✓
Store the API key in a Kubernetes Secret and mount it as a volume inside the container
Why this is correct
Secrets are designed for sensitive data; volume mounts avoid exposure in environment variable listings.
- ✗
Store the API key in a Kubernetes Secret and expose it as an environment variable
Why it's wrong here
Environment variables from Secrets can be leaked through process dumps or logs.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-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 →
Same concept, more angles
3 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?
medium- A.volumes: - name: secret-volume secret: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
- B.volumes: - name: secret-volume configMap: name: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
- ✓ C.volumes: - name: secret-volume secret: secretName: db-secret containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets
- D.containers: - name: app env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
Why C: It uses the `secret` volume type with the `secretName` field to reference the 'db-secret' Secret, and mounts it at /etc/secrets via a volumeMount. This adheres to the best practice of mounting secrets as volumes rather than injecting them as environment variables, which can be exposed in process listings or logs.
Variation 2. A security best practice is to avoid storing secrets in environment variables. Which is a secure alternative for injecting secrets into a pod?
medium- ✓ A.Use the Kubernetes Secret Store CSI driver to mount from external store
- B.Store secrets in ConfigMap and reference them in the pod
- C.Embed the secret directly in the pod definition YAML
- ✓ D.Mount the Secret as a volume
Why A: Both mounting the Secret as a volume (D) and using the Kubernetes Secret Store CSI driver to mount from an external store (A) are secure alternatives to environment variables. D uses tmpfs to avoid persisting secrets to disk, while A integrates with external secret stores and avoids storing secrets in etcd. The original explanation only justifies D and does not address why A is incorrect.
Variation 3. Which of the following is the best practice for providing sensitive data like passwords to a pod?
easy- ✓ A.Mount secrets as volumes into the pod.
- B.Use environment variables to inject secrets directly.
- C.Pass secrets via command-line arguments.
- D.Hardcode the secret in the container image.
Why A: Mounting secrets as volumes into the pod is the best practice because it ensures that secrets are stored in a tmpfs (RAM-backed) filesystem, which is never written to disk and is automatically cleaned up when the pod terminates. This approach also allows the kubelet to update the secret contents in the volume without restarting the pod, and it avoids exposing the secret in process listings, logs, or environment variable 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.