CKS Practice Question: After setting up etcd encryption at rest using…

Answer analysis

Option-by-option breakdown

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

• ✗

  A ConfigMap in the etcd namespace

  Why it's wrong here

  The encryption key is not stored in any Kubernetes object such as a ConfigMap. The kube-apiserver reads the key from a local file, the EncryptionConfiguration, specified via the --encryption-provider-config flag at process startup. Even if a ConfigMap existed in a namespace named 'etcd', the API server would not consume it dynamically, and etcd itself has no concept of Kubernetes namespaces. Furthermore, putting key material in a ConfigMap would expose it in etcd, which is exactly what encryption at rest is meant to protect.

• ✗

  A Secret in the kube-system namespace

  Why it's wrong here

  A Secret in the kube-system namespace is a tempting but incorrect choice because the EncryptionConfiguration is delivered as a file, not as a Secret object. If the key were stored as a Secret, it would itself be persisted in etcd and require encryption, creating a bootstrap problem. Moreover, the API server loads the encryption configuration only once at startup; it does not watch or fetch a Secret containing the key at runtime. Secrets are also base64-encoded, not a secure way to store sensitive key material when the entire datastore is at risk.

• ✓

  The EncryptionConfiguration file itself

  Why this is correct

  The correct answer is the EncryptionConfiguration file itself: this YAML file contains a 'keys' list, and each key entry includes a 'secret' field with the actual encryption key material. The file is passed to the kube-apiserver using the --encryption-provider-config flag, and the API server uses those keys to encrypt data written to etcd and decrypt data read from etcd. Because the file holds the keys in plaintext, it must be protected with restrictive filesystem permissions and is typically mounted from a secure location; any rotation requires editing this file and restarting the API server. This is the only mechanism Kubernetes uses for encryption-at-rest key delivery.

• ✗

  An annotation on the etcd pod

  Why it's wrong here

  An annotation on an etcd pod is not a valid storage location for encryption keys because annotations are metadata fields on Kubernetes objects and are stored in etcd themselves, meaning they would not be protected from unauthorized etcd access. More importantly, etcd pods do not perform or need the encryption key; encryption and decryption are handled by the kube-apiserver, which intercepts resource writes and reads. Annotations are also limited to 256KB, are visible via the object's metadata, and offer no intended mechanism for secret delivery to other components, making them completely unsuitable for key material.

Go deeper

Related to this question