Match each etcd security configuration to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Encrypts communication between etcd clients and the etcd server
Encrypts communication between etcd cluster members
Requires clients to present a valid certificate to access etcd
Encrypts etcd data stored on disk (requires manual configuration)
Limits which users or clients can perform operations on etcd keys
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
Client certificate authentication: Requires clients to present a valid certificate signed by a trusted CA.
In this matching exercise, each etcd security configuration should be paired with its correct description. Common confusions arise between client-to-server TLS and peer-to-peer TLS due to similar wording. Client-to-server TLS secures communication between clients and the cluster, while peer-to-peer TLS secures inter-member communication. Client certificate authentication and RBAC are distinct security features.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
Client-to-server TLS: Encrypts communication between etcd members.
Why it's wrong here
This statement misidentifies the traffic protected by client-to-server TLS. Client-to-server TLS secures the etcd client endpoint (default port 2379) for connections from clients such as kube-apiserver, whereas traffic between etcd members is secured by separate peer-to-peer TLS on port 2380 with its own peer certificate flags. Deploying only client-to-server TLS leaves inter-member Raft communication unprotected.
Peer-to-peer TLS: Encrypts communication between etcd clients and the cluster.
Why it's wrong here
This statement confuses the two distinct TLS listeners in etcd. Peer-to-peer TLS encrypts communication among etcd members for Raft consensus and data replication, using peer certificates and the --peer-client-cert-auth flag. The channel between etcd clients and the cluster is instead protected by client-to-server TLS on port 2379. Applying peer flags to the client listener would fail to secure client connections.
Client certificate authentication: Requires clients to present a valid certificate signed by a trusted CA.
Why this is correct
Client certificate authentication is an identity-verification mechanism, not merely encryption: when etcd runs with --client-cert-auth=true and --trusted-ca-file, it requires every client connection to present a certificate signed by the trusted CA before any request is processed. This ensures that only authenticated components, such as the Kubernetes API server with its client certificate, can reach etcd. It provides strong mutual TLS where the server validates the client's identity in addition to encrypting the session.
RBAC: Controls who can access which etcd resources based on roles.
Why this is correct
RBAC is an authorization layer that operates after TLS has established identity, controlling which authenticated users or roles can read or write specific key prefixes in etcd. For example, an etcd role can be granted read-write access to '/registry' for kube-apiserver while denying access to other keys or disallowing certain methods. This fine-grained control complements client certificate authentication, which only verifies who is connecting, by governing what that caller is allowed to do.
Client-to-server TLS: Encrypts communication between etcd clients and the etcd cluster.
Why this is correct
Client-to-server TLS specifically encrypts all traffic on the etcd client listener, the endpoint used by clients such as kube-apiserver to store and retrieve cluster state. This is enabled with --cert-file and --key-file on the server, and it protects sensitive data like secrets and ConfigMaps from eavesdropping on the network between the client and the etcd cluster. Unlike client certificate authentication, it does not by itself verify the client's identity unless --client-cert-auth is also enabled.
Peer-to-peer TLS: Encrypts communication between etcd members.
Why this is correct
Peer-to-peer TLS protects the proprietary communication channel among etcd members, including Raft consensus messages, heartbeat signals, and replicated state snapshots, on the peer port (default 2380). It is configured with --peer-cert-file and --peer-key-file and, for mutual authentication, --peer-client-cert-auth. Without this TLS layer, an attacker on the network could observe or tamper with internal cluster coordination traffic even if the client endpoint is properly secured.
Quick reference
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
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 →
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.