easyMultiple Select
CKS Practice Question: Which TWO of the following are valid methods to…
Which TWO of the following are valid methods to restrict etcd access? (Choose two.)
⚠ Common exam trap
It's easy for candidates to confuse network-level controls (firewall rules) or API server flags with actual etcd authentication/authorization mechanisms, or mistakenly believe etcd supports password authentication like traditional databases.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use TLS client certificates for authentication
Etcd supports mutual TLS (mTLS) authentication, where the client (e.g., kube-apiserver) presents a client certificate signed by the etcd CA. This ensures that only authenticated clients can communicate with etcd, effectively restricting access. Option C is correct because etcd has its own Role-Based Access Control (RBAC) system, which can be enabled to restrict read/write operations to specific users or roles, providing fine-grained access control.
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 firewall rules to restrict access to etcd port 2379
Why it's wrong here
Firewall rules can block connections to etcd's client port (2379) and/or peer port (2380), but they operate at the network layer and cannot distinguish between legitimate and malicious requests that originate from an allowed host. They also do not provide any authentication of the client identity or authorization for specific key operations, so a compromised workload running on a trusted node could still reach etcd unimpeded. Thus, while a useful defensive layer, they are not an etcd-specific access control mechanism.
- ✓
Use TLS client certificates for authentication
Why this is correct
TLS client certificate authentication is one of the two native, supported ways to restrict access to etcd. When etcd is started with --client-cert-auth=true, the server requires every client to present a certificate signed by a trusted CA, and it can optionally check the certificate's common name against a configured allowlist. This provides strong, transport-level authentication that prevents unauthenticated clients from contacting the etcd API, which is essential because etcd stores all Kubernetes cluster state.
- ✓
Enable etcd RBAC
Why this is correct
etcd RBAC is the other native access-control mechanism; after creating users and roles, you can enable auth so that every request must be authenticated (typically via TLS client cert or username/password) and then authorized against role-based permissions. These permissions can be very granular, allowing read/write access only to specific key prefixes, which is important because kube-apiserver needs full access while other clients should be restricted. RBAC is an authorization layer that works on top of TLS client authentication, not a substitute for it.
- ✗
Use etcd's built-in password authentication
Why it's wrong here
etcd does not have a standalone password authentication mechanism for restricting access to the datastore. Although etcd's RBAC system allows you to define users with passwords, that is a user database for auth, not a transport-level authentication method; without requiring TLS client certificates or enabling RBAC auth, etcd accepts connections from anyone. Even when RBAC user/password credentials are used, they are only valid over a secure TLS connection, so this option does not describe a valid way to restrict etcd on its own.
- ✗
Set the --etcd-certfile flag on kube-apiserver
Why it's wrong here
The --etcd-certfile flag on kube-apiserver specifies the TLS client certificate that the API server presents to etcd when establishing a connection. It is part of how the API server authenticates itself to etcd, not a mechanism for restricting access to etcd or controlling which clients are allowed. Restricting access is done on the etcd side, by requiring client certificates with --client-cert-auth or by enabling etcd RBAC; setting this flag alone does not prevent other clients from connecting.
Quick reference
Access Control Model Comparison
| 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
Related to this question
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 →
JA
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.