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.

• ✗

  Store them in ConfigMaps [wrong]

  Why it's wrong here

  ConfigMaps are designed for non-confidential configuration data and are not encrypted at rest; by default they are stored as plaintext in etcd, without the built-in encryption options available for Secrets. Unlike Secrets, ConfigMaps do not have dedicated mechanisms for scoped access or rotation, and they are often used in ways that expose data to all workloads in a namespace. Even if a cluster enables encryption for Secrets, ConfigMaps typically remain unencrypted, so placing sensitive values there breaks the intended security boundary.

• ✓

  Store them in Secrets and mount them as volumes [CORRECT]

  Why this is correct

  Storing Secrets and mounting them as volumes is a best practice because this method exposes data to the container as files on a filesystem, avoiding leakage through environment variables or process listings. Mounted Secrets support file-level permissions (e.g., read-only) and can be updated in place, allowing applications to pick up changes without redeployment. Additionally, the use of Secrets with volume mounts enables fine-grained RBAC controls and integrates with etcd encryption for Secrets, providing defense in depth for sensitive data.

• ✗

  Store them as environment variables in the Pod spec [wrong]

  Why it's wrong here

  Storing sensitive data as environment variables in the Pod spec exposes it in the process environment, which can be read by any process running in the container (e.g., via /proc/1/environ) and may leak through debugging or logging tools. Unlike volume-mounted Secrets, environment variables are also included in the mutable Pod object, so anyone with read access to the Pod via the Kubernetes API can see them. This approach lacks the file permissions and atomic update capability that mounted Secrets provide, making it a less secure practice.

• ✗

  Store them as labels on Pods [wrong]

  Why it's wrong here

  Pod labels are key-value metadata used for grouping and selecting objects; they are stored in plaintext in etcd and appear in API responses, meaning any identity with get/list access to Pods can read them. Labels are not subject to Secret-specific protections such as encryption at rest or access control via RBAC, and they do not support automatic rotation or per-file permissions. Using labels for sensitive data also violates their intended purpose, as label values are restricted to simple strings without special characters, further limiting their suitability.