mediumMultiple Choice
CKS Practice Question: A security audit reveals that etcd does not…
A security audit reveals that etcd does not encrypt data at rest. Which resource must be created to enable encryption?
⚠ Common exam trap
Candidates often confuse etcd encryption with TLS or secret management, assuming a Secret or ConfigMap alone enables encryption, when in fact the EncryptionConfiguration YAML is the mandatory resource that the API server reads to apply encryption at rest.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
EncryptionConfiguration YAML file and pass it to the API server via --encryption-provider-config
Kubernetes enables etcd data-at-rest encryption through an EncryptionConfiguration YAML file, which defines how to encrypt resources at the API server level. This file is passed to the kube-apiserver via the `--encryption-provider-config` flag, allowing providers like `aescbc` or `secretbox` to encrypt etcd data transparently.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Secret with encryption key
Why it's wrong here
A Kubernetes Secret is itself an object stored in etcd; if the encryption key were placed in a Secret, the key would reside in etcd in plaintext (or would depend on the encryption layer that the key is supposed to enable). This creates a bootstrap problem: the API server needs the encryption configuration and key before it can read any objects, including Secrets. The encryption configuration must be a static file on the API server host, not a Secret.
- ✗
Deployment for etcd with encryption flag
Why it's wrong here
etcd does not have an encryption flag for per-resource data-at-rest encryption; it only handles TLS for transport. In Kubernetes, the API server is responsible for encrypting resources before they are persisted in etcd and decrypting them on read. Passing an encryption-related flag directly to etcd would neither configure the API server's encryption providers nor cover the required resources, so it is not a valid approach.
- ✗
ConfigMap with encryption key
Why it's wrong here
A ConfigMap is also a Kubernetes object stored in etcd, and storing the encryption key there would place the key in the same datastore that is supposed to be protected, defeating the purpose. Moreover, the API server must load the encryption key during startup, before any API objects (including ConfigMaps) can be retrieved, so it cannot depend on a ConfigMap. The key must be available locally on the API server's filesystem via the --encryption-provider-config file.
- ✓
EncryptionConfiguration YAML file and pass it to the API server via --encryption-provider-config
Why this is correct
This is the standard and correct method: you define an EncryptionConfiguration YAML file that lists the encryption providers (e.g., aescbc, aesgcm, secretbox, identity) and the resources to encrypt (e.g., secrets, configmaps), then pass the file path to the kube-apiserver using the --encryption-provider-config flag. The API server uses the first non-identity provider to encrypt data before writing to etcd, and all listed providers are tried for decryption, enabling key rotation. The file must be readable by the kube-apiserver process and protected with restrictive permissions.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A security audit reveals that the etcd datastore is not encrypted at rest. Which resource should be created to enable encryption of secrets at rest?
medium- ✓ A.EncryptionConfiguration
- B.EtcdEncryption
- C.EncryptionConfig
- D.SecretEncryption
Why A: To enable encryption of secrets at rest in Kubernetes, you must create an EncryptionConfiguration resource. This resource defines which encryption providers (e.g., AES-CBC, secretbox) to use and how to encrypt resources stored in etcd. The kube-apiserver reads this configuration via the --encryption-provider-config flag and applies it to all resources in the specified resource group, such as secrets.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.