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.

• ✓

  Use Kubernetes Secrets with encryption at rest enabled

  Why this is correct

  Kubernetes Secrets can be encrypted at rest via the EncryptionConfiguration resource, where the kube-apiserver encrypts matching resources (e.g., secrets, configmaps) before writing them to etcd. Supported providers include AES-CBC, AES-GCM, and KMS for envelope encryption, which allows key management via cloud KMS or on-premises HSMs. Without this configuration, Secrets are stored as plaintext base64 in etcd, so enabling EncryptionConfiguration is a critical hardening step to protect Secret data at rest. Remember that this protects data on disk, but you still need RBAC and network policies to restrict access to Secrets in transit and at runtime.

• ✗

  Store secrets in ConfigMaps and use them in pods

  Why it's wrong here

  ConfigMaps are designed for non-sensitive configuration data and have no native encryption mechanism; they are stored as plaintext in etcd using base64 encoding, which is trivially reversible. Even if you enable EncryptionConfiguration, ConfigMaps are not intended to hold confidential material, and using them for secrets exposes data to any user with read access to the resource. Moreover, Secret objects support fine-grained RBAC and are the configured input for many Kubernetes integrations, whereas ConfigMaps lack the same data-encryption semantics. Because ConfigMaps are not encoded with any confidentiality guarantee, storing secrets in them is a security anti-pattern.

• ✗

  Commit secrets to a private Git repository

  Why it's wrong here

  Committing secrets to a private Git repository does not protect them from compromise: anyone with repository access—including contractors, CI/CD pipelines, or a compromised developer laptop—can read them, and they are permanently persisted in the commit history even after deletion. Git itself does not encrypt file contents at rest, and protection relies entirely on repository permissions that are notoriously difficult to keep tight across teams. Additionally, rotating a secret that lives in Git requires rewriting history and may still leak the old value through forks, caches, or pull-request diffs. This is why modern practices use dedicated secret-management tools like SOPS or git-crypt that encrypt secrets before committing.

• ✗

  Store secrets directly in the application code

  Why it's wrong here

  Hardcoding secrets directly in application code is insecure because it couples the secret to the source code and exposes it to anyone who can read the repository or inspect the compiled artifact. It also makes rotation extremely difficult: you must modify, rebuild, and redeploy the application every time the secret changes, which increases the risk of outages and leaks. Secrets in code may also be logged, printed in stack traces, or displayed in debuggers, and they violate the principle of least privilege by giving every developer access to every secret. Secure alternatives include referencing Secrets mounted as volumes or using environment variables, both of which can be updated independently of the application code.

• ✓

  Use an external secret manager like HashiCorp Vault with a sidecar or CSI driver

  Why this is correct

  Using an external secret manager like HashiCorp Vault provides a higher security boundary by storing sensitive data outside Kubernetes, with built-in capabilities such as dynamic secret generation, short-lived credentials, automatic rotation, and comprehensive audit logging. A sidecar container that fetches secrets via the Vault Agent can write them to a shared emptyDir volume, while the CSI driver exposes secrets directly as a volume mount, both preserving the 'one-writer' principle and allowing revocation without redeploying endpoints. These solutions avoid storing plaintext secrets in etcd and let you integrate with cloud IAM and services such as KMS wrapping, giving you centralized policy enforcement and revocation. Unlike native Secrets or ConfigMaps, Vault can also provide just-in-time access and lease expiration, dramatically reducing the blast radius of a leaked secret.

Go deeper

Related to this question