CKS Minimize Microservice Vulnerabilities Practice Question
Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)
⚠ Common exam trap
The exam often tests the misconception that Base64 encoding is a form of security, or that storing secrets in ConfigMaps is acceptable because ConfigMaps can be encrypted, but the exam expects you to know that ConfigMaps are for non-sensitive data and that external secrets managers or volume mounts are the correct approaches for secret management.
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
✓
Mount Secrets as volumes instead of environment variables
Mounting secrets as volumes is more secure than using environment variables. When secrets are injected as environment variables, they can be exposed through the process environment (e.g., via `/proc/self/environ` or `env` command) and are more likely to be accidentally logged or leaked. Mounting as a volume ensures the secret is only available as a file in the container's filesystem, and the secret data is not visible in the process list or environment dumps, reducing the attack surface.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Base64 encode the secret in the YAML manifest
Why it's wrong here
Base64 encoding is not encryption; it is a trivial reversible encoding scheme that provides no confidentiality against anyone holding the YAML. The Kubernetes API stores Secret values as base64 by default, but this is purely a serialization format, not a security control. An attacker with read access to the manifest can decode the secret in seconds, and relying on base64 gives a false sense of security. Proper protection requires encryption at rest (KMS), RBAC, and secret rotation.
- ✗
Set the secret as a label on the pod
Why it's wrong here
Pod labels are metadata intended for resource selection and organization; they are visible in kubectl output and API responses to any user with list or get permissions. Putting a secret in a label exposes it through commands like kubectl get pods --show-labels or label selectors, and it can also leak into metrics, logs, and audit records. Kubernetes RBAC does not provide per-label access control, so there is no way to restrict who can read secret data embedded in labels. Labels should never hold sensitive information.
- ✓
Mount Secrets as volumes instead of environment variables
Why this is correct
Mounting a Secret as a volume (e.g., in /var/secrets) keeps the secret data out of the container's environment variables, which are exposed through /proc/<pid>/environ and can be inherited by child processes or captured in debug output. A mounted file also lets you set restrictive file permissions (e.g., 0400) and, with projected volumes or subPath, can be updated without restarting the container. However, this only mitigates runtime exposure; the Secret is still stored in etcd and should be protected with encryption at rest.
- ✓
Use an external secrets manager like HashiCorp Vault
Why this is correct
An external secrets manager like HashiCorp Vault centralizes secret storage outside the Kubernetes cluster, giving you advanced access control via policies, full audit trails, automated rotation, and the ability to issue dynamic, short-lived credentials. This reduces the risk of secrets being compromised in etcd, especially because Kubernetes Secrets are not encrypted at rest by default unless a KMS provider is configured. Integration mechanisms like the Vault Agent Injector or the Secrets Store CSI driver can deliver secrets to pods without writing them to kubelet disk or exposing them in environment variables, significantly narrowing the attack surface.
- ✗
Store secrets in ConfigMaps to leverage ConfigMap encryption
Why it's wrong here
ConfigMaps are not encrypted by default and are designed for non-sensitive configuration data, so storing secrets there actually increases risk because they are treated as ordinary config and may be more freely accessed by broader RBAC policies. The premise of 'leveraging ConfigMap encryption' is fundamentally flawed: Kubernetes does not encrypt ConfigMaps at rest unless a KMS provider is enabled, and even then, Secrets are the appropriate object with separate access controls. Secrets stored in ConfigMaps can also appear in logs or annotations where they are easier to leak. The correct approach is to use Secrets with proper encryption and access controls, or an external manager.
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.