CKS Minimize Microservice Vulnerabilities Practice Question
You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?
⚠ Common exam trap
Candidates often think environment variables or ConfigMaps are acceptable for secrets, but the CKS exam emphasizes that ConfigMaps are for non-sensitive data and environment variables can leak secrets via logs or /proc, while Vault integration requires secure token handling via Secrets or dedicated injectors.
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 Vault tokens in a Kubernetes Secret and mount them
Storing Vault tokens in a Kubernetes Secret and mounting them into pods is a valid integration approach. The token is retrieved from Vault (e.g., via a Kubernetes auth method) and stored as a Secret, which is then mounted as a volume or environment variable, allowing the application to authenticate with Vault and fetch secrets 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.
- ✗
Use environment variables from Vault with a script
Why it's wrong here
Using environment variables from Vault via a script is a manual, non-native pattern: you would need to run a shell script that authenticates to Vault, fetches the secret, and exports it as an env var before the main process starts. This approach leaves the secret visible in the process environment (e.g., /proc/<pid>/environ), which is readable by any process with the same user or by debugging tools, and it requires storing or passing Vault credentials somewhere, often in a ConfigMap or pod spec, which undermines security. It also misses Kubernetes-native features like volume mounting, rotation, or RBAC-based access control, making it an ad-hoc solution not recommended for production.
- ✓
Store Vault tokens in a Kubernetes Secret and mount them
Why this is correct
Storing a Vault token in a Kubernetes Secret and mounting that Secret as a volume or env var is technically valid — the token itself is protected at rest by etcd encryption (if enabled) and access is governed by RBAC, so it acts as a static bootstrap credential. However, this approach has a significant security downside: the Vault token is a long-lived, high-privilege credential that, once copied into the Secret, does not rotate automatically and could be exfiltrated if the Secret or its decrypted contents are exposed. It works for simple use cases, but because the token remains valid until its TTL or an explicit revocation, it is less secure than using Vault Agent or CSI, which handle dynamic, short-lived secrets.
- ✓
Use the Vault Agent Sidecar Injector to inject secrets into pods
Why this is correct
The Vault Agent Sidecar Injector is a Kubernetes admission webhook that mutates pod definitions to add a Vault Agent container alongside the application. The agent automatically authenticates to Vault using the pod's Kubernetes service account (via the Kubernetes auth method), fetches the requested secrets, and renders them into a shared emptyDir volume or supplies them as environment variables with templates, enabling the application to read secrets without ever knowing the Vault token. This pattern is secure because secrets are dynamic, short-lived, and never stored in the pod spec, and it integrates natively with Kubernetes lifecycle, but it requires running the injector and configuring annotations on each workload.
- ✓
Use the Vault CSI Provider to mount secrets as volumes
Why this is correct
The Vault CSI Provider implements the Container Storage Interface (CSI), allowing Kubernetes to mount secrets from Vault as volumes directly into pods. When a pod references a CSI volume with a Vault provider, the CSI driver calls Vault to fetch the secret at mount time and presents it as a file in the pod's filesystem, and it can optionally rotate secrets by updating the volume content when the secret changes. Unlike a static Secret, the CSI provider does not keep the Vault token or the secret itself in etcd—the pod fetches it on demand from Vault, so there is no long-lived copy in the cluster, making it a secure, on-demand integration that supports advanced features like secret renewal and revocation.
- ✗
Store Vault tokens in a ConfigMap and mount them into pods
Why it's wrong here
Storing Vault tokens in a ConfigMap is a clear anti-pattern because ConfigMaps are designed for non-sensitive, plain-text configuration data and are stored unencrypted in etcd by default, with no additional layer of protection like Kubernetes Secrets' optional encryption at rest. Anyone with read access to the ConfigMap directly reads the Vault token, and because ConfigMaps are often copied into logs, exported, or mounted broadly, they drastically increase the attack surface. Unlike Secrets, ConfigMaps also lack the same RBAC conventions and are not intended to hold credentials of any kind, so using one to store a Vault token would compromise the security of the entire Vault integration.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way 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 team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?
medium- A.Use a ConfigMap to mount secrets as files
- B.Store secrets as environment variables in the pod spec
- C.Use kubectl exec to copy secrets into the container at startup
- ✓ D.Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes
Why D: It follows the Kubernetes best practice of using a mutating admission webhook to inject a sidecar container (e.g., Vault Agent or Bank-Vaults) that authenticates with HashiCorp Vault, fetches secrets, and mounts them as volumes into the pod. This approach avoids storing secrets in etcd (as ConfigMaps or environment variables do) and eliminates the need for manual secret injection, aligning with the principle of least privilege and dynamic secret management.
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.