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.

• ✗

  Storing secrets as environment variables

  Why it's wrong here

  Storing secrets as environment variables is not a best practice because any process running in the same pod inherits the environment, and on Linux those values are exposed in /proc/<pid>/environ, which can be read by other processes with sufficient privileges. Secrets in environment variables also appear in shell history, CI/CD logs, and debugging output, and they cannot be easily rotated without restarting the workload. The recommended approach is to mount secrets as files into a read-only volume or use an external secrets provider with dynamic injection.

• ✗

  Using the default secret type (Opaque) for all secrets

  Why it's wrong here

  Using the default Opaque secret type for all secrets gives a false sense of security because Opaque merely indicates that the secret contains arbitrary user data, and the payload is only base64-encoded, not encrypted. The type itself offers no protection; anyone with permission to read the secret via the Kubernetes API can trivially decode the base64 representation. Security depends on RBAC restrictions, encryption at rest, and secure storage—not on the secret type—so designating secrets as Opaque does not address the actual risks.

• ✓

  Enabling encryption at rest for secrets

  Why this is correct

  Enabling encryption at rest for secrets is a core hardening measure because by default secrets are stored in etcd in base64-encoded plaintext, and an attacker who compromises etcd can read every secret in the cluster. Configure the kube-apiserver with an encryption provider such as AES-CBC, KMS, or AWS/GCP KMS, ensuring that the encryption keys are managed outside of etcd. This adds a layer of protection so that even if etcd backups or volumes are exposed, the secrets remain unreadable without the decryption keys.

• ✗

  Limiting the number of secrets in the cluster

  Why it's wrong here

  Limiting the number of secrets in a cluster does not inherently improve security because the risk is not in how many secrets exist but in how they are accessed, stored, and rotated. A single poorly protected secret with broad RBAC can compromise the entire cluster, whereas many secrets guarded by least-privilege policies, encryption, and automated rotation remain safe. Reducing the count may even lead to overloading one secret with multiple purposes, increasing the blast radius if it is exposed.

• ✓

  Using an external secrets management system like HashiCorp Vault

  Why this is correct

  Using an external secrets management system like HashiCorp Vault is a best practice because it centralizes secret storage with native features such as dynamic secret generation, automatic rotation, lease-based expiration, and detailed audit logs. Integrations like the Vault Secret Operator or CSI provider allow Kubernetes workloads to fetch secrets on demand without persisting them in etcd, reducing exposure in the cluster. This architecture decouples secret lifecycles from the platform, enabling fine-grained access control and ensuring that leaked secrets are short-lived and easily revoked.

Go deeper

Related to this question