hardMultiple Select
CKS Practice Question: Which three of the following are valid methods to…
Which three of the following are valid methods to restrict access to etcd? (Choose three.)
⚠ Common exam trap
CNCF often tests the distinction between access control (who can connect to etcd) and data protection (encryption at rest), leading candidates to incorrectly select encryption as a method to restrict access.
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
✓
Enable RBAC authorization on etcd
Etcd supports Role-Based Access Control (RBAC) natively since version 3.0. By enabling RBAC on etcd, you can define roles and permissions to restrict which users or processes can read or write to specific keys or prefixes. This is a direct method to secure the etcd datastore against unauthorized access.
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 RBAC authorization on etcd
Why this is correct
etcd ships with a built-in RBAC system that authenticates client identities and authorizes operations according to roles bound to users. You can define users and roles, and grant read or write access to specific key prefixes (for example, /registry/) so only kube-apiserver's credentials can modify cluster state. This is a direct, API-level control that restricts which authenticated principal can execute etcd operations, making it a valid access-control method.
- ✗
Disable the etcd API and use only the embedded etcd in control plane
Why it's wrong here
The etcd API is the only interface kube-apiserver uses to persist and retrieve the entire cluster state, including pods, services, and secrets. Embedded etcd exists only for local development or testing environments; in a real cluster, etcd runs as a separate cluster, and disabling or removing its client API would make it impossible for the control plane to function. There is no legitimate production configuration that uses embedded etcd, and even if it did, it would still expose an API—disabling it entirely is not a viable restriction method.
- ✓
Use firewall rules to limit access to etcd port 2379
Why this is correct
Firewall rules act as a network-layer control that restricts which source IPs or network segments can reach etcd's client port 2379 (and peer port 2380). By allowing only the kube-apiserver's address and administrative jump hosts, you dramatically reduce the attack surface and prevent malicious or compromised nodes from directly contacting etcd. This complements authentication and authorization by stopping unauthenticated network connections before they reach etcd's TLS or RBAC layers, but it does not in itself identify or authorize the caller.
- ✓
Use TLS client certificates to authenticate clients
Why this is correct
etcd supports mutual TLS authentication through the --client-cert-auth flag, requiring every client to present a certificate issued by a trusted CA. The certificate's common name or organization can then be mapped directly to an etcd username or group, enabling per-principal authorization when combined with RBAC. This is a valid method because it provides strong cryptographic identification of the client, so only hosts holding valid certificates can establish an authenticated etcd session.
- ✗
Encrypt etcd data at rest using EncryptionConfiguration
Why it's wrong here
EncryptionConfiguration is a kube-apiserver feature that encrypts Kubernetes Secrets (and other resources) at rest, so data written to etcd is ciphertext on disk. While this protects the confidentiality of data if the filesystem is stolen or copied, it does not place any restriction on which clients can call the etcd API over the network; any user with valid etcd credentials can still read or modify the encrypted values. Access control and encryption solve different problems, and encryption at rest is not an alternative to etcd authentication, authorization, or network filtering.
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 →
Same concept, more angles
5 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are valid methods to restrict etcd access? (Choose two.)
easy- A.Use firewall rules to restrict access to etcd port 2379
- ✓ B.Use TLS client certificates for authentication
- ✓ C.Enable etcd RBAC
- D.Use etcd's built-in password authentication
- E.Set the --etcd-certfile flag on kube-apiserver
Why B: 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.
Variation 2. You need to restrict access to etcd so that only the API server can communicate with it. Which method should you use?
hard- ✓ A.Configure etcd with TLS client certificates and require authentication
- B.Set the etcd flag --peer-auto-tls=true
- C.Configure etcd to use RBAC with a role that allows only the API server
- D.Use a firewall rule to restrict access to etcd's port from the API server's IP
Why A: Etcd supports mutual TLS (mTLS) authentication, which requires clients to present a valid TLS certificate signed by a trusted CA. By configuring etcd with `--client-cert-auth=true` and providing the API server's client certificate, you ensure that only the API server (or any client with a valid certificate) can communicate with etcd. This is the recommended Kubernetes approach to restrict access to etcd, as it cryptographically verifies the identity of the client.
Variation 3. Which THREE of the following are valid methods to restrict access to etcd in a Kubernetes cluster? (Select THREE)
hard- ✓ A.Use TLS certificates for client and server authentication
- ✓ B.Enable RBAC authorization in etcd
- C.Use simple username and password authentication
- D.Put etcd on the same network as the API server without firewall
- E.Encrypt etcd data at rest
Why A: Option A is correct because etcd natively supports mutual TLS (mTLS), where both the client (kube-apiserver) and the etcd server present X.509 certificates signed by a trusted CA, ensuring only authenticated peers can connect via --cert-file, --key-file, --trusted-ca-file, and --client-cert-auth. Option B is correct because etcd supports its own RBAC layer (distinct from Kubernetes RBAC) that grants roles and permissions to users and roles via etcdctl role add / user grant-role, restricting which keys a client can read or write. Option C is not valid because etcd deprecated and removed simple username/password authentication in favor of TLS and RBAC. Option D is not valid because placing etcd on the same network without a firewall exposes ports 2379/2380 and does not restrict access at all. Option E is not valid because encrypting data at rest protects stored data confidentiality but does not restrict who can access etcd.
Variation 4. Which TWO of the following are valid ways to restrict access to etcd? (Select 2)
medium- ✓ A.Enable RBAC on etcd by using etcdctl to create users and roles, then run `etcdctl auth enable` (optionally starting etcd with `--auth-token=jwt` to specify JWT token type).
- B.Use --peer-auto-tls=true to auto-generate certificates.
- C.Use --admission-control=NodeRestriction on etcd.
- ✓ D.Use TLS client certificates for authentication.
- E.Set --client-cert-auth=false to disable authentication.
Why A: Option A is correct because etcd natively supports role-based access control: you create users and roles with etcdctl (e.g., `etcdctl user add`, `etcdctl role add`, `etcdctl role grant-permission`), then enable enforcement with `etcdctl auth enable`, and the `--auth-token=jwt` flag selects JWT as the token type for authenticated requests. Option D is correct because etcd supports TLS client certificate authentication, where the client presents a certificate signed by a trusted CA and etcd validates it against its `--trusted-ca-file` and `--cert-file`/`--key-file` configuration, optionally combined with `--client-cert-auth=true`. Option B is not a valid access-restriction method for etcd clients: `--peer-auto-tls` only auto-generates certificates for peer-to-peer communication between etcd cluster members, not for authenticating external clients. Option C is incorrect because `--admission-control=NodeRestriction` is a kube-apiserver flag for limiting what kubelets can modify, not an etcd option. Option E is incorrect because setting `--client-cert-auth=false` disables client certificate authentication rather than restricting access, weakening security.
Variation 5. Which THREE of the following are valid ways to restrict access to etcd? (Select 3)
hard- ✓ A.Enable etcd RBAC to restrict read/write access
- B.Use HTTP instead of HTTPS
- C.Disable client authentication for simplicity
- ✓ D.Use firewall rules to restrict network access to etcd
- ✓ E.Use TLS client certificates for authentication
Why A: Etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.
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.