easyMultiple ChoiceObjective-mapped
CKS EncryptionConfiguration Practice Question
Which of the following is the recommended method to enable encryption at rest for secrets in etcd using the EncryptionConfiguration?
⚠ Common exam trap
Candidates might assume `secretbox` is also correct, but this question specifically asks for the recommended method, making only `aescbc` the correct answer.
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 provider: aescbc
The recommended encryption provider for Kubernetes secrets at rest is `aescbc` (AES-CBC), as per the official documentation. While `secretbox` is a valid provider, it is less commonly used and not the default recommendation. Options 'encryption' and 'aesgcm' are invalid or deprecated.
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 provider: aescbc
Why this is correct
The aescbc provider is a valid and recommended encryption provider for Kubernetes Secrets at rest. It uses AES in CBC mode with PKCS#7 padding and includes an HMAC-SHA256 integrity check over the ciphertext, providing both confidentiality and integrity, and it is the standard provider for enabling encryption at rest in a cluster.
- ✗
Use provider: encryption
Why it's wrong here
The value 'encryption' is not a valid provider name in a Kubernetes EncryptionConfiguration. The valid providers are aescbc, aesgcm, secretbox, and identity; specifying 'encryption' will cause the API server to reject the configuration and fail to start, so it is not a usable method.
- ✗
Use provider: secretbox
Why it's wrong here
The secretbox provider is technically a valid encryption provider based on the NaCl secretbox construction, but it is not commonly used and is generally not recommended for Kubernetes encryption at rest. Because it is a non-standard choice and not the default or widely tested provider in the Kubernetes ecosystem, selecting it is not the correct method for enabling encryption.
- ✗
Use provider: aesgcm
Why it's wrong here
The aesgcm provider is deprecated and not recommended for encrypting Kubernetes data at rest. Although it is a valid provider name, its use of AES-GCM with a random nonce can be vulnerable to nonce reuse if key rotation is mishandled, and it does not authenticate the ciphertext as robustly as aescbc, making it an unsuitable choice for production secret encryption.
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
Courseiva writes every CKS question from scratch — 114 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.