mediumMultiple Choice
CKS Encrypt etcd data at rest using AES-CBC Practice Question
You need to encrypt etcd data at rest using AES-CBC. Which encryption provider should you specify in the EncryptionConfiguration?
⚠ Common exam trap
Watch out — candidates often confuse the Kubernetes provider name 'aescbc' with the generic algorithm name 'aes-256-cbc' or other encryption modes like 'aesgcm', but the exam expects exact knowledge of the Kubernetes-specific provider identifiers as defined in the official documentation.
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
✓
aescbc
(aescbc) is correct because Kubernetes supports AES-CBC encryption via the 'aescbc' provider in the EncryptionConfiguration. This provider uses AES in Cipher Block Chaining mode with a 32-byte key for encryption at rest, as specified in the Kubernetes documentation for encrypting etcd data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
aesgcm
Why it's wrong here
aesgcm is not a recognized provider in Kubernetes' EncryptionConfiguration. It represents an authenticated encryption mode that differs fundamentally from AES-CBC; it requires a unique nonce per encryption and is not implemented as a built-in at-rest provider. While GCM is used inside some KMS integrations, selecting it as a provider name would cause the API server to reject the configuration.
- ✓
aescbc
Why this is correct
aescbc is the exact, built-in provider name for AES-CBC encryption at rest in Kubernetes. It uses AES in CBC mode with a random initialization vector prepended to the ciphertext and PKCS#7 padding, and requires a 32-byte key for AES-256 strength. This provider is explicitly supported in EncryptionConfiguration and is the correct answer for encrypting etcd data with AES-CBC.
- ✗
aes-256-cbc
Why it's wrong here
aes-256-cbc describes the algorithm and key size but is not a valid provider identifier in Kubernetes EncryptionConfiguration. The provider string is simply 'aescbc'; the key length is determined by the key provided (32 bytes for AES-256), not by including it in the name. Using 'aes-256-cbc' as the provider would fail to start or be ignored by the kube-apiserver.
- ✗
secretbox
Why it's wrong here
secretbox is a valid Kubernetes encryption provider that uses NaCl's XSalsa20-Poly1305 authenticated encryption, not AES-CBC. It provides both confidentiality and integrity, whereas AES-CBC in aescbc offers only confidentiality. Since the question specifically asks for AES-CBC, aescbc is the required provider, not secretbox.
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 — 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.