CKS Minimize Microservice Vulnerabilities Practice Question
A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?
⚠ Common exam trap
A common trap in Kubernetes exams is confusing the deprecated `--experimental-encryption-provider-config` flag with the current `--encryption-provider-config` flag. Also, remember that base64 encoding is not encryption; it only obfuscates data.
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
✓
Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider
The `--encryption-provider-config` flag on the kube-apiserver points to a YAML file containing an `EncryptionConfiguration` resource. Within that configuration, specifying the `aescbc` provider enables AES-CBC encryption for Secrets at rest, with the encryption key managed locally by the API server. This is the only option that satisfies the requirement for AES-CBC encryption with a locally managed key.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable etcd encryption by setting --experimental-encryption-provider-config
Why it's wrong here
The --experimental-encryption-provider-config flag existed only in early Kubernetes releases and was later renamed to --encryption-provider-config; modern kube-apiserver binaries treat the 'experimental' spelling as an unknown flag and will refuse to start. Even if a deprecated variant were accepted, passing it without a valid EncryptionConfiguration file would not encrypt anything—it would either fail validation or be ignored. This option is wrong because it uses a nonexistent flag and omits the required configuration for actual encryption.
- ✗
Use Secret resource's 'data' field with base64 encoding
Why it's wrong here
Base64 encoding (the normal format for the Secret's data field) is a reversible encoding, not encryption; it merely converts raw bytes into an ASCII representation and provides zero confidentiality. Anyone with read access to etcd, a backup, or a compromised workload can decode the base64 string and recover the plaintext secret instantly. Proper at-rest encryption requires a cipher such as AES, configured through the EncryptionConfiguration, not base64 obfuscation.
- ✓
Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider
Why this is correct
This is correct because --encryption-provider-config points to an EncryptionConfiguration file that defines the 'aescbc' provider, which encrypts Secret data with AES in CBC mode before it is written to etcd. The kube-apiserver uses the first non-identity provider in the list to encrypt new secrets and tries all listed providers for decryption, enabling smooth key rotation without rewriting existing data. With this configuration, etcd stores only ciphertext, protecting secrets from anyone who gains direct access to the underlying etcd database.
- ✗
Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider
Why it's wrong here
The identity provider is a valid entry in an EncryptionConfiguration, but it performs no encryption—it acts as a pass-through that stores and returns data in plaintext. If you configure the file with identity as the only provider despite setting the correct flag, every secret will still be written to etcd without any cryptographic protection. This option is wrong because it does not actually encrypt anything, even though the flag name itself is correct.
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
Learn chapter
TLS Certificates and API Server Security
Key term
etcd Encryption
etcd encryption is the process of protecting data stored in etcd, the key-value store used by Kubernetes, by encoding it so that unauthorized users cannot read it even if they gain access to the storage.
Key term
API Server Security
API Server Security refers to the practices, configurations, and controls that protect the Kubernetes API server from unauthorized access, data breaches, and malicious attacks.
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 →
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.