CKS Minimize Microservice Vulnerabilities Practice Question
An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?
⚠ Common exam trap
The CKS exam often tests the misconception that encryption at rest is configured directly on etcd or via an environment variable, when in fact it is a kube-apiserver configuration that intercepts writes to etcd.
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
✓
Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.
Kubernetes does not have a native `kubectl encrypt secrets` command, and etcd itself does not handle encryption configuration directly. Instead, encryption at rest is configured by creating an `EncryptionConfiguration` YAML resource that defines providers (e.g., `aescbc`, `secretbox`) and passing it to the `kube-apiserver` via the `--encryption-provider-config` flag. The API server then transparently encrypts secrets before writing them to etcd and decrypts them on read.
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 kubectl encrypt secrets command.
Why it's wrong here
kubectl does not have an 'encrypt' subcommand in any supported version. The kubectl CLI is a client for the Kubernetes API and only handles request/response operations; it never directly writes to etcd or transforms stored data. Secret encryption is performed transparently by the kube-apiserver before the resource is persisted, so a user-facing CLI command cannot trigger or configure it.
- ✗
Modify the etcd configuration to enable encryption.
Why it's wrong here
Kubernetes does not encrypt data by modifying etcd's own configuration; etcd simply stores the bytes it receives from the kube-apiserver. Encryption must be applied at the API server layer because it is the only component that understands the resource structure and has the keys. Putting an encryption setting in etcd's startup flags or config file would either be unsupported or would encrypt the entire etcd database, not individual Secret objects, and would not integrate with Kubernetes identity/authorization. The only supported path is the apiserver's --encryption-provider-config flag.
- ✓
Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.
Why this is correct
This is the correct approach: you create an EncryptionConfiguration object (YAML) that declares one or more encryption providers (e.g., aescbc, secretbox, or kms) and a key list, then start the kube-apiserver with --encryption-provider-config=/path/to/this/file. When a Secret is written, the apiserver encrypts it with the first non-identity provider before sending it to etcd; when read, it tries providers in order until one can decrypt. This gives you at-rest encryption with per-resource control, key rotation, and support for external KMS providers.
- ✗
Set the environment variable ENCRYPT_SECRETS=true on all nodes.
Why it's wrong here
No environment variable named ENCRYPT_SECRETS exists in Kubernetes. The control plane components are configured primarily through command-line flags and configuration files, not through generic environment variables that would be present on all nodes. Even if you set such a variable on every node, the kube-apiserver would ignore it, and the etcd data would remain plaintext. Encryption at rest is enabled exclusively by the --encryption-provider-config flag on the kube-apiserver, which points to a YAML resource containing the provider and key settings.
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. To encrypt secrets at rest in Kubernetes, an administrator configures an EncryptionConfiguration. What is the correct flag to pass to the kube-apiserver to use this configuration?
hard- ✓ A.--encryption-provider-config=/path/to/config.yaml
- B.--feature-gates=EncryptionAtRest=true
- C.--encryption-key=/path/to/config.yaml
- D.--encryption-config=/path/to/config.yaml
Why A: The `--encryption-provider-config` flag is the exact command-line option that the kube-apiserver expects to locate the EncryptionConfiguration YAML file. This flag tells the API server to read the configuration that defines which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting Kubernetes secrets at rest in etcd.
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.