CKS Practice Question: Which TWO actions should be taken to secure etcd…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Enable TLS authentication for etcd peer and client communication

  Why this is correct

  TLS authentication for etcd encompasses both peer and client communication, encrypting data in transit and requiring certificates for mutual identity verification. This prevents eavesdropping, man-in-the-middle attacks, and unauthorized access from compromised nodes. In a Kubernetes control plane, etcd peer communication (port 2380) and client communication with the API server (port 2379) must both be TLS-protected, as etcd stores cluster state and secrets. Without TLS, anyone with network access could read or alter cluster data, defeating the security of the entire cluster.

• ✗

  Run etcd as a DaemonSet to ensure high availability

  Why it's wrong here

  Running etcd as a DaemonSet is inappropriate because etcd is a stateful distributed store requiring stable node identity, persistent storage per peer, and quorum-based consensus. A DaemonSet's pod-per-node model conflicts with etcd's need for a fixed cluster membership and dedicated disk-backed storage; replacing an etcd pod on a new node without its data would break quorum. In production, etcd should run as a static pod or systemd service on dedicated members, with its data directory on a persistent, high-performance disk. While DaemonSet could technically schedule pods, it does not provide the stability or operational controls etcd requires.

• ✗

  Disable client certificate authentication for etcd

  Why it's wrong here

  Disabling client certificate authentication for etcd would allow any client to connect without proving its identity, since etcd would accept unauthenticated requests over the client port. etcd supports mutual TLS where both the API server and etcd present certificates, ensuring that only the authenticated kube-apiserver can read or write cluster state. Turning off client cert auth would expose all secrets and configuration to any network entity that can reach port 2379, severely compromising the control plane. Certificate-based authentication is a mandatory control in a properly secured Kubernetes cluster.

• ✗

  Enable the NodeRestriction admission plugin on etcd

  Why it's wrong here

  The NodeRestriction admission plugin limits the Kubernetes API actions a kubelet can perform, such as modifying its own Node object, and is enforced by the kube-apiserver. It is completely unrelated to etcd, which is a separate distributed key-value store and does not admit or validate API objects. Enabling NodeRestriction on etcd is impossible because etcd does not implement Kubernetes admission controllers. The correct way to secure etcd is through TLS, access control, and network restrictions, not through API server admission plugins.

• ✓

  Restrict access to etcd using network policies or firewall rules

  Why this is correct

  Restricting access to etcd via network policies or firewall rules limits which hosts can reach the etcd client and peer ports, reducing the attack surface exposed by the control plane. Even with TLS enabled, defense-in-depth suggests allowing only the kube-apiserver nodes to connect to the client port (2379) and only peer etcd members to the peer port (2380). This prevents lateral movement by compromised workloads or nodes that might otherwise attempt to interact with etcd directly. Network-level restrictions complement authentication and encryption, ensuring that unauthorized network paths are blocked before they can exploit any potential vulnerabilities.

Go deeper

Related to this question