CKS Minimize Microservice Vulnerabilities Practice Question
Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)
⚠ Common exam trap
A common trap in Kubernetes exams is the misconception that storing secrets as environment variables is secure because they are 'in-memory'. However, environment variables are easily exposed through pod logs, exec commands, and /proc, making them less secure than volume mounts with proper access controls.
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 CSI driver to mount secrets as volumes
The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.
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 secrets as environment variables
Why it's wrong here
Passing secrets as environment variables exposes them in the process environment of the container, making them readable by any process running in the pod and accessible through /proc or debugging tools. They also appear in the pod's spec, visible to anyone with API access, and are commonly printed in logs when applications dump environment variables, creating an unnecessary leakage vector.
- ✓
Use a CSI driver to mount secrets as volumes
Why this is correct
A CSI driver for secrets, such as the Secrets Store CSI Driver, mounts secrets as formatted files into the pod's filesystem, pulling them from external providers like Vault or AWS Secrets Manager at runtime. This avoids storing sensitive data in Kubernetes etcd, enables secrets to be rotated without restarting pods, and keeps secrets out of environment variables and container images, significantly reducing exposure.
- ✗
Embed secrets in container images
Why it's wrong here
Embedding secrets directly into a container image bakes them into image layers, meaning anyone who can pull the image—including through a registry—can extract the secret from the layer metadata. This also prevents independent rotation; rotating requires rebuilding and redeploying the entire image. Furthermore, secrets embedded in images persist in the registry history, violating the principle of minimal exposure and making supply chain attacks more impactful.
- ✓
Use an external secrets manager like Vault with a sidecar
Why this is correct
Using an external secrets manager like Vault with a sidecar container allows the application to fetch secrets dynamically at runtime through a local API or proxy, centralizing secret storage and enforcing fine-grained access control and audit logging. This approach removes secrets from Kubernetes etcd, avoids embedding them in images, and enables automatic rotation since the sidecar can re-fetch values on a schedule without redeploying the pod, while the application never directly accesses the external backend.
- ✗
Store secrets in a ConfigMap
Why it's wrong here
ConfigMaps are plain‑text data stores intended for non‑sensitive configuration; although they can contain any data, they are not protected by Kubernetes' secrets mechanisms. Secrets stored in ConfigMaps are written to etcd as plain base64 without any purpose‑built encryption-at-rest or access controls, and any RBAC rule granting access to ConfigMaps would expose the credentials. They are also more likely to be treated as generic configuration and accidentally shared or logged.
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.