CKA Practice Question: Cluster Architecture, Installation & Configuration
A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?
⚠ Common exam trap
Test-takers frequently confuse encryption at rest (data on disk) with encryption in transit (TLS), leading candidates to select TLS-based options, or assuming that etcd itself handles encryption at rest when it is actually the kube-apiserver that performs the encryption before writing to etcd.
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
✓
Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.
Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption 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.
- ✗
Use LUKS to encrypt the disk partition where etcd data is stored.
Why it's wrong here
LUKS disk-level encryption protects all etcd data by encrypting the underlying block device, but it is infrastructure-level and requires manual setup and key management outside the Kubernetes API. It does not allow per-resource or per-secret encryption policies, and it is not the standard or Kubernetes-native control-plane mechanism for encrypting secrets at rest. While it adds a layer of defense, it does not satisfy the common CKA objective of configuring API-server-driven secret encryption.
- ✓
Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.
Why this is correct
An EncryptionConfiguration resource defines the order and type of providers (such as aescbc, aesgcm, secretbox, or kms) for protecting specific API resource types. The kube-apiserver must be started with --encryption-provider-config=/path/to/encryption-config.yaml, and when it writes data like Secrets to etcd it encrypts that data using the chosen provider (aescbc uses AES-CBC with a randomly generated IV and a 32-byte key). This is the canonical, Kubernetes-native mechanism for encryption at rest and is exactly what the CKA objectives expect.
- ✗
Use TLS certificates to encrypt communication between etcd and the API server.
Why it's wrong here
TLS certificates and mutual TLS between etcd peers and between the API server and etcd protect data while it is in transit over the network. They do not affect how data is stored on disk, so a snapshot or direct read of the etcd data files still yields plaintext values unless additional encryption is applied. This confusion conflates transport encryption with at-rest encryption, so it is incorrect for this scenario.
- ✗
Configure etcd to use encryption at rest by setting --experimental-encryption-provider.
Why it's wrong here
The etcd daemon has no flag like --experimental-encryption-provider; server-side encryption is not an etcd feature. Kubernetes implements encryption at rest at the API server layer, which is the component that serializes and writes Secrets to etcd. The real configuration is an EncryptionConfiguration object passed to the API server's --encryption-provider-config flag, not a setting on etcd.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA 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 CKA exam.