easyMultiple Choice
CKS Practice Question: Which kube-apiserver flag enables encryption at…
Which kube-apiserver flag enables encryption at rest for secrets?
⚠ Common exam trap
A common mix-up: candidates confuse the `--encryption-provider-config` flag with a non-existent flag like `--enable-encryption` or `--secret-encryption`, assuming encryption at rest is enabled by a simple boolean flag rather than a configuration file reference.
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
✓
--encryption-provider-config
The `--encryption-provider-config` flag is the correct answer because it is the kube-apiserver flag that specifies the path to a configuration file containing the encryption providers (like `aescbc`, `secretbox`, or `aesgcm`) and the associated keys for encrypting Kubernetes secrets at rest. This flag enables the encryption at rest feature for secrets and other resources, as defined in the encryption configuration file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
--encryption-provider-config
Why this is correct
The --encryption-provider-config flag is the only option that exists on the kube-apiserver for enabling encryption at rest. It accepts the path to an EncryptionConfiguration YAML file, which defines the secret (or other resource) types to encrypt and the ordered list of providers (identity, aescbc, aesgcm, secretbox) along with their keys. When the API server starts, it reads this file and uses it to encrypt data before writing to etcd and to decrypt it on read, making this the correct mechanism.
- ✗
--encryption-key-file
Why it's wrong here
--encryption-key-file is not a recognized kube-apiserver flag. Unlike TLS setups where a server might take a separate key file, Kubernetes expects all encryption keys to be embedded in the EncryptionConfiguration file referenced by --encryption-provider-config. If you attempt to start the API server with this flag, it will fail with an invalid flag error because it is simply not part of the apiserver's option surface.
- ✗
--secret-encryption
Why it's wrong here
--secret-encryption is not a valid flag either; there is no resource-specific switch on the kube-apiserver for encrypting Secrets. At-rest encryption is not a per-resource toggle but is defined generically through the EncryptionConfiguration, which lists resources such as secrets, configmaps, or custom resources under the 'resources' section. The API server only knows about --encryption-provider-config for enabling this functionality.
- ✗
--enable-encryption
Why it's wrong here
--enable-encryption is not a valid flag because Kubernetes does not use a boolean switch to turn on at-rest encryption. Encryption is enabled by referencing an EncryptionConfiguration file via --encryption-provider-config; merely setting an 'enable' flag would not provide the required provider and key details. Kube-apiserver strictly validates its flags, so an unrecognized flag like this is rejected at startup.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.