hardMultiple Choice
CKS Practice Question: An etcd cluster uses TLS for peer and client…
An etcd cluster uses TLS for peer and client communication. Which command correctly tests connectivity to an etcd member with client certificate authentication?
⚠ Common exam trap
CNCF often tests the misconception that only the client certificate is needed for mTLS, causing candidates to forget the `--key` flag, or that only the CA certificate is sufficient for client authentication, leading them to omit the client certificate and key entirely.
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
✓
etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health
It provides all three required TLS components for mutual TLS (mTLS) authentication: the CA certificate (`--cacert`) to verify the server's identity, the client certificate (`--cert`) for the client's identity, and the client key (`--key`) to prove possession of the private key. The `endpoint health` command then performs a TLS handshake and checks the etcd member's health over HTTPS. Without any of these three, the connection will fail due to certificate validation errors or missing client authentication.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health
Why it's wrong here
This command is missing two essential TLS elements: the --cacert flag to verify the server's certificate chain and the --key flag to accompany the client certificate. Without --cacert, the etcdctl client cannot validate that the server at 10.0.0.1:2379 is genuinely the etcd endpoint, leaving it vulnerable to man-in-the-middle attacks during the TLS handshake. Additionally, because etcd is configured for mutual TLS, the server requires the client to present both a certificate (--cert) and its private key (--key); omitting the key means the client certificate cannot be used for authentication, so the server will reject the connection.
- ✓
etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health
Why this is correct
This is the correct command because it supplies all three components required for mutual TLS against an etcd cluster: --cacert sets the CA certificate used to verify the server's identity, --cert provides the client certificate, and --key provides the corresponding private key for that client certificate. With these flags, etcdctl can establish an authenticated and encrypted HTTPS connection, successfully complete the TLS handshake, and then query the /health endpoint to check cluster status. The command precisely follows the standard pattern for etcd client authentication when the cluster enforces both server-side and client-side certificate verification.
- ✗
etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health
Why it's wrong here
This command includes the CA certificate (--cacert), which allows the client to verify the server's identity, but it omits the client certificate (--cert) and client key (--key). Since the etcd cluster uses TLS for client communication and is configured to require mutual TLS, the server will demand a valid client certificate during the handshake. Without presenting any client certificate, the client fails the server's authentication step, so the endpoint health request is rejected before any status check can occur—even though the server itself passed verification.
- ✗
etcdctl --endpoints=http://10.0.0.1:2379 endpoint health
Why it's wrong here
This command uses an http:// URL instead of https://, so it attempts a plaintext connection to a TLS-enabled etcd endpoint. The etcd server is configured to accept only TLS-encrypted client communication, so it will refuse or drop the non-TLS connection, and the health check will fail. Even if the server were misconfigured to accept HTTP, this command would be insecure because it sends no CA, client certificate, or key, meaning there is no server authentication and no client authentication—violating the mutual TLS requirement entirely.
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.