CKS Practice Question: Which THREE 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.

• ✗

  Use HTTP instead of HTTPS to reduce overhead

  Why it's wrong here

  Plain HTTP transmits all data in cleartext, exposing etcd's sensitive cluster state — including Secret objects and ConfigMaps — to any observer on the network. The negligible performance savings of avoiding TLS does not justify a trivial man-in-the-middle impersonating the apiserver or reading leadership election data. HTTPS should always be used so that communication remains confidential and tamper-resistant.

• ✓

  Encrypt secrets at rest using EncryptionConfiguration

  Why this is correct

  EncryptionConfiguration, passed via the apiserver's --encryption-provider-config flag, defines a set of key providers (aescbc, aesgcm, or secretbox) that encrypt specific resources — typically Secrets — before they are written to etcd and decrypt them on reads. This protects data at rest, meaning if an attacker steals an etcd snapshot or physically accesses the storage files, they only see ciphertext. Without this, any read of etcd returns plaintext secrets.

• ✓

  Enable RBAC authorization on etcd

  Why this is correct

  etcd supports Role-Based Access Control (RBAC) that restricts operations to authenticated users by granting verbs (get, put, delete) over key ranges. By default etcd has authentication disabled, so any client that can reach the port can read and modify all keys. Enabling RBAC requires creating root users and roles, and then configuring the apiserver's --etcd-certfile and --etcd-keyfile so that only the apiserver has write access to the cluster's key namespace.

• ✗

  Open etcd port 2379 to all network interfaces

  Why it's wrong here

  Binding the etcd client port (2379) to all interfaces exposes the datastore to every process and host that can reach your network, bypassing any apiserver-level authorizers. An attacker who reaches this port may read secrets, delete keys, or alter cluster objects, effectively taking over the cluster. The port should listen on 127.0.0.1 when etcd is colocated with the apiserver, or be protected by firewall/network policies to only allow the apiserver's IP address.

• ✓

  Enable TLS client certificates for authentication

  Why this is correct

  Mutual TLS (mTLS) with client certificates is the only way to cryptographically prove that an etcd client is actually the Kubernetes API server. When etcd starts with --cert-file, --key-file, and --client-cert-auth, it requires every client to present a certificate signed by a trusted CA; requests without a valid certificate are rejected. This both encrypts traffic and authenticates the peer, preventing unauthorized nodes from reading or writing cluster state even if they can reach the port.

Go deeper

Related to this question