CKS Minimize Microservice Vulnerabilities Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Pass secrets as environment variables

  Why it's wrong here

  Passing secrets as environment variables leaks them through /proc/<pid>/environ, which is readable by any process with the same UID or root, and they may also be exposed via debugging tools, health checks, or error logging. Environment variables are also immutable during the pod's lifetime; rotating the secret requires recreating the pod, and there is no fine-grained access control on individual variables.

• ✗

  Embed secrets directly in the pod YAML definition

  Why it's wrong here

  Embedding secrets directly in the pod YAML definition places sensitive data in plaintext within the pod spec, which is often stored in version control, CI/CD logs, or backup files. Anyone with read access to the pod object or the API server can see the secret, and unless encryption at rest is enabled, it is stored unencrypted in etcd. This practice also tightly couples the secret to a specific workload, making rotation and auditing difficult.

• ✓

  Mount secrets as volumes in pods

  Why this is correct

  Mounting secrets as volumes in pods is the Kubernetes-native best practice because the secret is rendered as individual files on a tmpfs volume, which is memory-backed and not written to disk. File permissions default to 0444, and can be tightened to 0400; additionally, when the secret is updated, kubelet eventually updates the mounted files, allowing for rotation without restarting the pod. This approach avoids exposure via /proc/environ and limits access to containers that explicitly mount the volume.

• ✗

  Store secrets as plain text in ConfigMap

  Why it's wrong here

  Storing secrets as plain text in a ConfigMap is inappropriate because ConfigMaps are designed for non-confidential configuration data and are stored in plaintext in etcd unless cluster-level encryption at rest is enabled. ConfigMaps also lack secret-specific features such as encryption, per-key access control, and integration with external secret rotation. This practice increases the risk that sensitive data will appear in logs or backups, and it can lead to overly permissive RBAC policies that grant broad access to all ConfigMaps.

• ✓

  Use an external secrets manager like HashiCorp Vault with CSI driver

  Why this is correct

  Using an external secrets manager like HashiCorp Vault with the CSI driver allows secrets to be mounted as volumes on demand without ever storing them in etcd, pod specs, or ConfigMaps. The CSI driver fetches the secret from Vault at mount time and can refresh it periodically, enabling dynamic secrets and fine-grained audit logging while minimizing the blast radius of a leaked secret. This approach is especially valuable in multi-tenant or production environments where long-lived static secrets are a security risk.

Go deeper

Related to this question