CKS Minimize Microservice Vulnerabilities Practice Question
Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?
⚠ Common exam trap
A common misconception is that modifying etcd configuration directly enables encryption at rest, when in fact encryption is a kube-apiserver concern managed via the `--encryption-provider-config` flag and `EncryptionConfiguration` resource.
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
✓
Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration
The `aescbc` encryption provider is one of the supported providers in Kubernetes for encrypting secrets at rest. Specifying it in the `EncryptionConfiguration` tells the kube-apiserver which encryption algorithm to use when writing data to etcd. Without a provider like `aescbc`, secrets are stored in plaintext in etcd.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration
Why this is correct
Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration is essential because the provider determines the cryptographic algorithm and key used to encrypt secrets at rest. `aescbc` uses AES-CBC with a 256-bit key and is the recommended provider for most clusters. Without a provider, the configuration is invalid and the API server cannot perform any encryption, so data would remain plaintext in etcd.
- ✓
An EncryptionConfiguration YAML file defining encryption providers and resources to encrypt
Why this is correct
The EncryptionConfiguration YAML file is the core artifact that defines which Kubernetes resources (e.g., secrets) should be encrypted and which encryption providers are available for that purpose. It contains a list of resources, each with an ordered list of providers; the first provider in the list is used for new writes, while all providers are used to decrypt existing data. This file is loaded by the API server only when referenced via the `--encryption-provider-config` flag, making it a required component of any encryption-at-rest setup.
- ✗
Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets
Why it's wrong here
Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` is an optional post-configuration task, not a requirement for enabling encryption at rest. While existing secrets are not automatically encrypted by the API server simply because a new EncryptionConfiguration is applied, this command forces a rewrite of all secrets so that they are stored as ciphertext. Skipping this step does not prevent the encryption configuration from working; it only leaves pre-existing secrets in plaintext until they are naturally updated or manually rewritten.
- ✓
Passing the `--encryption-provider-config` flag to the kube-apiserver
Why this is correct
Passing the `--encryption-provider-config` flag to the kube-apiserver is the mandatory mechanism that tells the API server where to find the EncryptionConfiguration file. Without this flag, the API server completely ignores any encryption configuration and continues to store data in plaintext, even if the YAML file exists on the node. The flag is typically set in the kube-apiserver static pod manifest or systemd unit, and a restart is required for changes to take effect.
- ✗
Modifying the etcd configuration to enable encryption at rest
Why it's wrong here
Modifying the etcd configuration to enable encryption at rest is unnecessary and incorrect because Kubernetes performs encryption in the API server, not in etcd. The API server encrypts objects with the configured provider before writing them to etcd, so etcd only ever receives ciphertext and does not need any special encryption settings for this feature. Additionally, etcd has its own optional encryption mechanisms for protecting the etcd data files, but those are entirely separate from Kubernetes-level encryption-at-rest and are not a prerequisite for it.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
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. You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?
medium- A.No, because only Secrets in namespaces with a specific annotation are encrypted.
- B.Yes, but only if the Secret was created after the API server restart.
- C.No, because the data is still visible in the API response.
- ✓ D.Yes, because encryption at rest applies to the storage layer (etcd), not the API response.
Why D: Encryption at rest in Kubernetes protects data when it is stored in etcd, the underlying key-value store. The API server decrypts the data transparently when serving it via the API, so the base64-encoded plaintext visible in `kubectl get secret -o yaml` is the decrypted output, not the raw encrypted data. The EncryptionConfiguration object ensures that new or updated Secrets are encrypted before being written to etcd, but the API response always shows the plaintext after decryption.
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.