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.

• ✓

  Mount secrets as volumes into the pod.

  Why this is correct

  Mounting secrets as volumes provides a filesystem-based interface that keeps the secret out of process listings, environment variables, and command-line arguments. The volume is mounted read-only and backed by tmpfs, so the secret is never written to a container's writable layer. You can also use defaultMode to set strict file permissions, limiting access to the specific UID/GID of the container. This approach also enables secrets to be updated (with some delay) by simply changing the Secret object, without a coordinated environment variable update.

• ✗

  Use environment variables to inject secrets directly.

  Why it's wrong here

  Environment variables are visible via the /proc/<pid>/environ file, meaning any process on the node with sufficient privileges can read them, and they may also appear in logs or be exposed by `kubectl describe pod`. Because environment variables are inherited by all child processes, a compromised process leaks the secret to anything else in the same container. They also cannot be configured with fine-grained file permissions, and once set, rotation requires a pod restart to force the new value into the environment. This makes them a poor choice for protecting sensitive data.

• ✗

  Pass secrets via command-line arguments.

  Why it's wrong here

  Passing secrets as command-line arguments embeds them in the container runtime's process list, which can be read with `ps` or via /proc/<pid>/cmdline by anyone with node-level access. Unlike environment variables, command-line arguments are also captured in the container runtime's audit logs and may be included in core dumps or crash reports. Additionally, the arguments become part of the pod's specification, meaning anyone with read access to the pod definition can see the plaintext secret. They offer no way to restrict access per-file or to set mount permissions, making them one of the least secure injection methods.

• ✗

  Hardcode the secret in the container image.

  Why it's wrong here

  Hardcoding a secret in a container image permanently embeds it in the image layers, so anyone with pull access to the registry—or who obtains the image—can extract the secret using standard tools. This approach provides zero ability to rotate the secret without rebuilding, re-pushing, and re-deploying the entire image. It also violates the principle of least privilege because the secret is available to every user who can access the image, regardless of their actual need. Furthermore, the secret may be exposed in image build logs, version control, and public registries, creating a long-term security liability.

Go deeper

Related to this question