mediumMultiple Choice
CKS Secure etcd communication Practice Question
An administrator wants to secure etcd communication. Which of the following is required?
⚠ Common exam trap
It's easy for candidates to assume HTTPS alone (Option A) is sufficient for securing etcd, overlooking the requirement for mutual TLS authentication with client certificates to prevent unauthorized clients from connecting 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
✓
Enable TLS with client certificate authentication
Etcd, as a distributed key-value store, requires TLS encryption with mutual authentication (client certificates) to secure communication between the API server and etcd, as well as between etcd peers. The `--etcd-servers` flag in kube-apiserver must point to HTTPS endpoints, and `--etcd-certfile` and `--etcd-keyfile` enable client certificate authentication, ensuring that only authenticated clients can access 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.
- ✗
Set --etcd-servers to use HTTPS
Why it's wrong here
The --etcd-servers flag tells kube-apiserver to reach etcd at a given URL, so setting it to https:// merely changes the client-side URL scheme from http to https. This does nothing to make etcd itself secure, because the etcd server must still be started with its own TLS configuration (e.g., --cert-file, --key-file, --client-cert-auth) to actually speak TLS. Moreover, kube-apiserver must present a client certificate via --etcd-certfile and --etcd-keyfile for mutual TLS to work; simply changing the scheme is insufficient.
- ✗
Use SSH tunneling between etcd members
Why it's wrong here
SSH tunneling can proxy etcd traffic over an encrypted channel, but it is not a native etcd feature and is never used for etcd member-to-member communication. etcd peers use their own HTTP/2 transport, and TLS must be configured directly via etcd's peer flags such as --peer-cert-file and --peer-client-cert-auth. An SSH tunnel would not require or validate client certificates at the etcd layer, leaving the endpoint itself unauthenticated and out of the control plane's certificate lifecycle.
- ✓
Enable TLS with client certificate authentication
Why this is correct
The correct approach is to configure etcd to require TLS and, crucially, mutual TLS by setting --client-cert-auth=true along with a --trusted-ca-file, which forces every client to present a certificate signed by a trusted CA. This authenticates clients cryptographically, prevents man-in-the-middle attacks, and encrypts all data in transit between etcd clients (primarily kube-apiserver) and the etcd server. It is the standard, native mechanism etcd provides for securing client communication.
- ✗
Enable etcd RBAC
Why it's wrong here
etcd RBAC governs authorized operations on keys and roles after authentication, providing authorization for that specific user's access rights. It does not encrypt the network channel, protect against packet interception, or verify the identity of a connecting host beyond the username used. Enabling RBAC without TLS still leaves communication in plaintext and vulnerable to spoofing, so it is not a transport security mechanism.
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 →
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.