CKS Practice Question: Which TWO of the following are valid methods to…

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 encryption for client-to-server communication.

  Why this is correct

  TLS encryption for client-to-server communication is mandatory for protecting the data plane between the Kubernetes API server and etcd. It ensures that all cluster secrets, ConfigMaps, and resource definitions are encrypted in transit, preventing sniffing and man-in-the-middle attacks. Additionally, TLS provides server identity verification, allowing clients to authenticate the etcd endpoint and avoid connecting to a rogue server. Without this, sensitive cluster state would be transmitted in plaintext, compromising the entire control plane.

• ✓

  Enable peer authentication using TLS certificates.

  Why this is correct

  Peer authentication using TLS certificates verifies the identity of each etcd member before allowing participation in the raft consensus group. This prevents an unauthorized or rogue node from joining the cluster and reading or corrupting etcd's data. It also protects against man-in-the-middle attacks between etcd peers, ensuring that only trusted members can send or receive consensus messages. This is a critical boundary for maintaining the integrity and confidentiality of cluster state in a multi-member etcd deployment.

• ✗

  Use HTTP instead of HTTPS for better performance.

  Why it's wrong here

  Switching from HTTPS to HTTP to improve performance is a false economy, as the security risk far outweighs any negligible speed gain. Without TLS, all etcd traffic—including authentication tokens, secrets, and cluster configuration—would traverse the network in plaintext, making it easy for attackers to intercept and manipulate. Modern hardware and optimized TLS implementations reduce the overhead to a fraction of a percent, so the performance difference is insignificant. This option undermines confidentiality and integrity with no practical benefit.

• ✗

  Disable client authentication to simplify configuration.

  Why it's wrong here

  Disabling client authentication for etcd removes the access control layer entirely, allowing anyone who can reach the etcd endpoint to read and write the cluster's full state, including all secrets and administrator credentials. This completely bypasses Kubernetes RBAC and abandons the principle of least privilege, making the cluster trivially compromisable. While it simplifies initial setup, it is catastrophic in production and violates baseline security hardening standards. Authentication is a non-negotiable defense for a data store holding the entire cluster's sensitive information.

• ✗

  Expose the etcd port (2379) on a public IP for easier monitoring.

  Why it's wrong here

  Exposing the etcd client port (2379) on a public IP is an extremely dangerous practice that turns the cluster's critical data store into a publicly reachable target. Even with authentication, this exposes the interface to brute-force attempts, protocol-level exploits, and denial-of-service attacks, and any misconfiguration or vulnerability becomes remotely exploitable. Proper monitoring should be done through authenticated metering or observability tools that access etcd over a private, restricted network, not by making the service accessible from the internet. Public exposure directly contradicts the principle of minimizing attack surface and is a leading cause of data breaches.

Go deeper

Related to this question