CKS Minimize Microservice Vulnerabilities Practice Question
An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?
⚠ Common exam trap
Test-takers frequently assume applying an EncryptionConfiguration and restarting the API server automatically encrypts all existing data, but Kubernetes only encrypts data on new writes, not retroactively.
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
✓
Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back
Kubernetes does not automatically encrypt existing secrets stored in etcd when an EncryptionConfiguration is applied. The encryption configuration only affects data written after the kube-apiserver is restarted; previously stored secrets remain in plaintext until they are read and rewritten (e.g., by running `kubectl get secret <name> -o yaml | kubectl replace -f -`). This behavior is by design, as the API server encrypts data on write, not retroactively.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The encryption provider is set to 'identity' which does not encrypt
Why it's wrong here
This option assumes the configured provider is 'identity', but that is unlikely because the admin explicitly created an EncryptionConfiguration. The identity provider is the default when no configuration exists, and it stores secrets as plaintext in etcd. If the admin had intended encryption, they would have configured a real encryption provider such as 'aescbc' or 'aesgcm', so this explanation does not match the scenario described.
- ✗
The kube-apiserver was not restarted after applying the configuration
Why it's wrong here
The admin explicitly stated that the kube-apiserver was restarted after applying the configuration, so this cannot be the cause. The EncryptionConfiguration is loaded once at API server startup, and a restart is indeed required for changes to take effect. Since the restart already happened, the lack of encryption must be due to something else, not a missed restart.
- ✓
Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back
Why this is correct
This is the correct answer. When a new EncryptionConfiguration becomes active, the API server only encrypts objects that are written to etcd after that point; any objects that already exist in etcd remain in their original unencrypted form until they are modified. To encrypt existing secrets, they must be rewritten by reading them and then performing a write operation, such as `kubectl get secret -o yaml | kubectl replace -f -` or by deleting and recreating them. The API server does not automatically backfill encryption for pre-existing data.
- ✗
The EncryptionConfiguration has a syntax error that caused it to be ignored
Why it's wrong here
A syntax error in the EncryptionConfiguration would not cause the API server to silently ignore the file; instead, the API server would fail to start or would log fatal errors during startup, because the configuration is parsed and validated at initialization. Since the admin reports the API server is running normally and applying the configuration did not break it, a syntax error is not a plausible explanation. Thus, this option is incorrect.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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. An admin creates the following EncryptionConfiguration to encrypt secrets at rest. After applying it, what must the admin do to ensure existing secrets are encrypted?
hard- ✓ A.Re-create the existing secrets
- B.Restart the kube-apiserver
- C.Delete the existing secrets and wait for them to be recreated automatically
- D.Nothing, the existing secrets are automatically encrypted
Why A: When an EncryptionConfiguration is applied to encrypt secrets at rest, the kube-apiserver uses the configured encryption provider to encrypt new or updated secrets as they are written to etcd. However, existing secrets that were stored in plaintext before the configuration was applied remain unencrypted in etcd. To ensure these existing secrets are encrypted, the admin must re-create them (e.g., by deleting and recreating them or using `kubectl get secret -o yaml | kubectl replace -f -`), which triggers a write to etcd through the encryption provider.
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.