mediumMultiple Select
CKS Practice Question: Which TWO of the following are recommended…
Which TWO of the following are recommended practices for etcd security?
⚠ Common exam trap
CNCF often tests the misconception that disabling TLS or exposing etcd is acceptable for monitoring or performance, when in reality etcd must always be isolated and encrypted to protect the cluster's root of trust.
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
✓
Restrict etcd access to only the API server and kubelets using firewall rules
Option C is correct because etcd stores all cluster state and secrets, so network access should be tightly restricted with firewall rules to only the components that legitimately need it—typically the API server (and kubelets in some topologies)—rather than being reachable by arbitrary hosts. Option E is correct because enabling TLS client certificate authentication ensures that only clients presenting a valid, trusted certificate can connect to etcd, providing mutual authentication and preventing unauthorized reads or writes to the datastore. The unmarked options do not belong: A is wrong because anonymous authentication would allow unauthenticated access to the cluster's most sensitive data, B is wrong because disabling TLS exposes etcd traffic to eavesdropping and tampering (and TLS overhead is not a valid reason to remove it), and D is wrong because exposing etcd on a public IP dramatically increases the attack surface and is never a recommended monitoring practice.
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 anonymous authentication for etcd
Why it's wrong here
Anonymous authentication must be disabled in etcd because it allows any unauthenticated client that can reach the etcd endpoint to read and modify the entire Kubernetes state, including secrets, ConfigMaps, and cluster configuration. The CIS Benchmark for Kubernetes mandates `--client-cert-auth=true` and explicitly forbids enabling anonymous access, as an attacker with network access could trivially extract or corrupt data. Therefore, anonymous auth is a severe security flaw and must never be enabled.
- ✗
Disable TLS for performance
Why it's wrong here
Disabling TLS for performance eliminates confidentiality and integrity between etcd clients and peers, enabling man-in-the-middle attackers to intercept or modify all data exchanged with the cluster. The performance benefit is negligible on modern hardware because TLS overhead is minimal compared to the risks, while Kubernetes requires `--cert-file`, `--key-file`, and peer certificates for secure control plane operation. Without TLS, the entire etcd cluster becomes exposed to eavesdropping and tampering, making this an unacceptable trade-off.
- ✓
Restrict etcd access to only the API server and kubelets using firewall rules
Why this is correct
Restricting etcd access to only the API server and kubelets using firewall rules is a foundational defense-in-depth measure because etcd stores the entire cluster state, including secrets and RBAC policies. Firewall rules, such as security groups or host-based iptables, should permit only the API server on the etcd client port (2379) and block all other hosts, reducing the attack surface even if a worker node is compromised. This complements mTLS by controlling which hosts can initiate connections, ensuring that only trusted components can interact with the data store.
- ✗
Expose etcd on a public IP for monitoring
Why it's wrong here
Exposing etcd on a public IP for monitoring is dangerous because the etcd API and its Prometheus metrics endpoint are served on the same port that handles sensitive data; there is no separate monitoring-only listener. A public IP allows attackers to attempt brute-force attacks, probe for vulnerabilities, and even read-only metrics can leak cluster topology and load information useful for lateral movement. Monitoring should be done via a secured internal network or a dedicated exporter, never by exposing etcd directly to the internet, as the CIS Benchmark explicitly warns against binding to publicly routable addresses.
- ✓
Enable TLS client certificate authentication
Why this is correct
Enabling TLS client certificate authentication on etcd (via `--client-cert-auth=true`) enforces mutual TLS, requiring every client to present a valid certificate signed by the cluster's CA before any request is processed. This is the primary authentication mechanism for the API server when it communicates with etcd, and it prevents unauthenticated clients or on-path attackers from impersonating legitimate users. mTLS ensures that only the API server, and any other explicitly authorized component, can read or write cluster data, making it a critical control for protecting the control plane.
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.