CKS Minimize Microservice Vulnerabilities Practice Question

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=/path/to/config.yaml

  Why this is correct

  The `--encryption-provider-config` flag points the kube-apiserver to an EncryptionConfiguration YAML file that defines which providers (like `aescbc`, `aesgcm`, or `secretbox`) to use for encrypting Secrets and other resources at rest. The file also holds the actual encryption keys under each provider and specifies the order in which providers are attempted for throttling and decryption. Without this flag, Kubernetes stores Secrets in etcd as plaintext, so this is the standard way to enable encryption.

• ✗

  --feature-gates=EncryptionAtRest=true

  Why it's wrong here

  Encryption at rest is not controlled by a feature gate; the `--feature-gates` flag toggles alpha/beta features, not persistent security configurations. Even if an `EncryptionAtRest` gate existed, it would only activate code paths, but it would not supply the required provider definitions, key material, or resource list. The kube-apiserver must be given an EncryptionConfiguration file via `--encryption-provider-config` to actually encrypt data before writing to etcd, so merely setting this gate does nothing.

• ✗

  --encryption-key=/path/to/config.yaml

  Why it's wrong here

  The kube-apiserver has no `--encryption-key` flag; encryption keys are never passed as a simple file path or command-line argument. Instead, keys (e.g., a base64-encoded 32-byte secret for `aescbc`) are embedded inside the `providers` section of the EncryptionConfiguration YAML, and each provider block references its own key. Passing only a key file would give the apiserver no information about which resources to encrypt, which provider algorithm to use, or how to handle multiple keys for rotation, so the command fails as an invalid flag.

• ✗

  --encryption-config=/path/to/config.yaml

  Why it's wrong here

  There is no `--encryption-config` flag in kube-apiserver; the actual flag name is longer and more explicit: `--encryption-provider-config`. This misconception likely arises because users remember the concept of an 'encryption config' file, but the apiserver expects a provider-specific configuration that maps resources to encryption providers and key sets. Using the shortened name would cause the apiserver to exit with an "unknown flag" error, so it is not a valid alternative.

Go deeper

Related to this question