CKS Minimize Microservice Vulnerabilities Practice Question
A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?
⚠ Common exam trap
CNCF often tests the misconception that restarting the API server or deleting/recreating Secrets is sufficient for re-encryption, when in fact the only way to re-encrypt existing data is to read and write it back through the API server.
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
✓
Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'
After rotating the encryption key in the EncryptionConfiguration, existing Secrets are still encrypted with the old key. To re-encrypt them with the new key, you must read all Secrets and write them back using 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. This triggers the API server to encrypt the data with the new key (the first provider in the list) during the write operation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete and recreate all Secrets
Why it's wrong here
Deleting and recreating all Secrets is a destructive operation that removes the existing Secret objects, including their metadata, resource versions, and any live references from workloads or controllers. The new Secrets would have new UIDs and resourceVersions, potentially breaking RBAC policies, admission webhooks, or tools that track object versions. It also requires manually reconstructing the Secret data, risking permanent data loss if the plaintext is not already available outside the cluster. This approach does not perform a controlled rewrite through the API server encryption path and is not a sanctioned key-rotation procedure.
- ✗
Restart the API server
Why it's wrong here
Restarting the API server only reloads the encryption configuration (including any new key added to the aescbc provider) for future write operations. It does not iterate over existing Secrets in etcd, so all previously stored ciphertext remains encrypted with the old key until each object is modified or replaced. Therefore, restarting the API server without subsequently performing a read/write cycle on every Secret leaves the old ciphertext in place and fails to complete the encryption key rotation.
- ✗
Run 'kubectl encrypt secrets --key new-key'
Why it's wrong here
The kubectl CLI does not expose an 'encrypt' subcommand; encryption and decryption are performed server-side by the kube-apiserver using the configured encryption providers (e.g., aescbc, kms), not by kubectl or client-side operations. Running 'kubectl encrypt secrets --key new-key' would fail with an unknown command error and cannot modify the encryption of existing resources. Key rotation is achieved by editing the EncryptionConfiguration, restarting the API server, and then rewriting Secrets via a resource update, not by a fictional kubectl command.
- ✓
Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'
Why this is correct
This command retrieves every Secret in all namespaces as YAML and pipes it to 'kubectl replace —f -', which submits an update request for each Secret. Because replace triggers a write, the API server reads the existing ciphertext from etcd, decrypts it with the old key, and re-encrypts it using the currently active encryption key (the first key in the aescbc provider's key list). This effectively migrates all existing Secrets to the new key without deleting them or losing data, making it the correct procedure for encrypting existing data with the new key.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.