CKS Practice Question: Which THREE options are valid methods to secure…

Answer analysis

Option-by-option breakdown

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

• ✗

  Set --auto-compaction-mode=periodic

  Why it's wrong here

  Setting --auto-compaction-mode=periodic is a maintenance control, not a security control. It tells etcd to automatically delete historical key-value revisions on an interval, preventing unbounded database growth by reclaiming storage space. This operation does not encrypt data, authenticate clients, or restrict network access, so it has no bearing on confidentiality, integrity, or availability from an adversarial perspective.

• ✓

  Enable TLS with peer and client certificates

  Why this is correct

  Enabling TLS with peer and client certificates secures etcd in two critical ways: it encrypts all communication between etcd members (peer traffic) and between the kube-apiserver and etcd (client traffic), preventing eavesdropping and man-in-the-middle attacks. Client-certificate authentication ensures only the kube-apiserver (with its properly signed certificate) can issue reads and writes to the etcd data store. Mutual TLS also protects against unauthorized nodes joining the etcd cluster, making it a foundational security control for the Kubernetes control plane.

• ✓

  Use a firewall to restrict access to etcd's port

  Why this is correct

  Using a firewall to restrict access to etcd's port (2379 for client traffic, 2380 for peer traffic) is a valid network-level security measure. Because etcd stores the entire cluster state—including secrets, ConfigMaps, and RBAC policies—limiting which hosts can reach these ports blocks any attacker without network path access from querying or modifying that data. A firewall complements the encryption and authentication provided by TLS: TLS handles confidentiality and authenticity of the data in transit, while the firewall shrinks the attack surface by enforcing a default-deny policy from untrusted networks.

• ✓

  Encrypt secrets at rest using EncryptionConfiguration

  Why this is correct

  Encrypting secrets at rest using EncryptionConfiguration is a valid security measure because etcd by default stores all data in plaintext, even though Kubernetes base64-encodes secret values before putting them in etcd (base64 is not encryption). With an EncryptionConfiguration, you can configure Kubernetes to encrypt resources, typically secrets, using an AES-GCM or AES-CBC key managed by the kube-apiserver before data is written to etcd. This protects the confidentiality of secrets if the etcd data files are copied or the underlying disk is compromised, and it is the only method on this list that secures data at rest.

• ✗

  Enable RBAC authorization in etcd

  Why it's wrong here

  Enabling RBAC authorization in etcd is not a standard or valid method for securing etcd in a Kubernetes cluster. While etcd does have its own built-in RBAC system for controlling individual users' access to etcd keys, the Kubernetes API server authenticates to etcd using a client TLS certificate, not via etcd usernames and passwords; it bypasses etcd's RBAC entirely. Overriding or relying on etcd RBAC could actually break the API server's ability to read/write cluster state, and the established best practice is to enforce authentication and authorization at the Kubernetes layer and via mTLS, not through etcd's separate, rarely used RBAC mechanism.

Go deeper

Related to this question