CKS Minimize Microservice Vulnerabilities Practice Question
To encrypt secrets at rest, which file must be modified on the control plane nodes?
⚠ Common exam trap
CNCF exams often test the misconception that encryption-at-rest is configured by modifying etcd's manifest or configuration files, when in reality it is the API server that handles encryption before data reaches etcd.
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
✓
/etc/kubernetes/manifests/kube-apiserver.yaml
To enable encryption of secrets at rest in Kubernetes, you must modify the kube-apiserver manifest file at `/etc/kubernetes/manifests/kube-apiserver.yaml` on control plane nodes. This file is a static Pod manifest that defines the API server's startup flags, including `--encryption-provider-config`, which points to an EncryptionConfiguration YAML file specifying the encryption providers (e.g., `aescbc`, `secretbox`) and keys. The API server is the component that writes and reads secrets from etcd, so it is the only place where encryption-at-rest configuration is applied.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
/etc/kubernetes/scheduler.conf
Why it's wrong here
The scheduler.conf file is the kubeconfig used by the kube-scheduler to authenticate to the API server. Encryption at rest is enabled exclusively through the API server's --encryption-provider-config flag, not through any scheduler component. The scheduler does not write to etcd directly, so changing this file cannot affect how secrets are stored.
- ✓
/etc/kubernetes/manifests/kube-apiserver.yaml
Why this is correct
This static pod manifest defines the kube-apiserver's runtime configuration, including command-line flags. To enable encryption at rest, you add the --encryption-provider-config flag here, which points to an EncryptionConfiguration YAML file that specifies the provider (e.g., aesgcm or kms). Because the API server is the only component that directly reads and writes secrets to etcd, this is the correct and canonical place to configure secret encryption.
- ✗
/etc/kubernetes/etcd.yaml
Why it's wrong here
etcd.yaml is the manifest for the etcd store itself, but Kubernetes does not perform secret encryption inside etcd—the API server handles that layer. Modifying etcd's configuration would only change its transport security or storage options, not add Kubernetes-level encryption. Even if etcd is encrypted at the disk level, that is not the same as the API server's provider-based encryption, and compliance controls often require the latter.
- ✗
/etc/kubernetes/kubelet.conf
Why it's wrong here
kubelet.conf is the kubelet's client configuration, used for its own connection to the API server and for managing pods on the node. It contains no settings for API server encryption, and the kubelet does not interact directly with etcd or manage secret persistence. Touching this file would affect node registration, not the encryption of secrets at rest.
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.