Courseiva
← CKS
Full test
hardMultiple Choice

CKS Practice Question: A security scan reports that the etcd data…

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

⚠ Common exam trap

Many exam-takers assume encryption at rest is configured directly on etcd (via flags or environment variables), when in fact it is a kube-apiserver-level feature that uses an EncryptionConfiguration resource and the --encryption-provider-config flag.

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

✓

Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config

Etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

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 etcdctl to encrypt the data directory

    Why it's wrong here

    etcdctl is a command-line client for interacting with etcd, not a tool for encrypting its storage backend. It can create snapshots, list keys, or manipulate data, but it never touches the on-disk format of the etcd data directory. Kubernetes encryption at rest is performed by the API server before data is written to etcd, so running etcdctl cannot protect existing or future data from disk-level access.

  • ✓

    Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config

    Why this is correct

    The correct procedure is to define an EncryptionConfiguration file that specifies the aescbc provider along with a valid key, then start kube-apiserver with the --encryption-provider-config flag pointing to that file. After restarting the API server, it will encrypt matching Kubernetes resources (e.g., Secrets) before persisting them to etcd and decrypt them on reads. This is the officially supported, cluster-wide mechanism for encryption at rest in Kubernetes.

  • ✗

    Set --encryption-provider=secretbox on etcd

    Why it's wrong here

    The etcd binary does not accept an --encryption-provider flag — that flag belongs to kube-apiserver. etcd's own storage layer has no general-purpose field-level encryption that integrates with Kubernetes, and secretbox is not a recognized etcd option. In the Kubernetes architecture, encryption happens in the API server, not in etcd, so configuring etcd this way is both syntactically invalid and architecturally wrong.

  • ✗

    Set ETCD_ENABLE_ENCRYPTION=true environment variable

    Why it's wrong here

    ETCD_ENABLE_ENCRYPTION is not a standard environment variable recognized by etcd or kube-apiserver. Kubernetes configuration for at-rest encryption is done declaratively via the EncryptionConfiguration YAML passed with a specific API server flag, not through environment variables. Relying on an env var also would not provide the necessary key management or provider selection that the API server's configuration requires.

About these practice questions

One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

4 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. You need to encrypt etcd data at rest using AES-CBC. Which encryption provider should you specify in the EncryptionConfiguration?

medium
  • A.aesgcm
  • ✓ B.aescbc
  • C.aes-256-cbc
  • D.secretbox

Why B: (aescbc) is correct because Kubernetes supports AES-CBC encryption via the 'aescbc' provider in the EncryptionConfiguration. This provider uses AES in Cipher Block Chaining mode with a 32-byte key for encryption at rest, as specified in the Kubernetes documentation for encrypting etcd data.

Variation 2. You have enabled etcd encryption at rest using an EncryptionConfiguration with aescbc provider. After applying the configuration, you create a new Secret. Which of the following is true regarding the encrypted Secret?

hard
  • A.All Secrets are encrypted because the EncryptionConfiguration applies to all resources.
  • B.All Secrets in the cluster, including existing ones, are immediately encrypted.
  • ✓ C.Only the new Secret is encrypted; existing Secrets remain in plaintext.
  • D.The new Secret is stored in plaintext because aescbc is not a valid provider.

Why C: When you apply an EncryptionConfiguration with aescbc provider, only newly created Secrets are encrypted at rest. Existing Secrets remain in plaintext because encryption is applied at write time; the API server does not retroactively re-encrypt data already stored in etcd. This is why option C is correct.

Variation 3. Which THREE of the following are valid fields in an EncryptionConfiguration YAML to encrypt secrets at rest?

medium
  • A.providers
  • ✓ B.resources
  • ✓ C.apiVersion
  • D.key
  • ✓ E.kind

Why B: `resources` is a valid field in an EncryptionConfiguration YAML that specifies which Kubernetes resources (e.g., secrets) should be encrypted. The EncryptionConfiguration object defines how to encrypt data at rest in etcd, and the `resources` field lists the resource types to encrypt, such as `secrets`. Without this field, the encryption configuration would not know which resources to apply encryption to.

Variation 4. You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

medium
  • A.EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1
  • B.EncryptionConfig with apiVersion v1
  • C.SecretEncryption with apiVersion v1
  • ✓ D.EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1

Why D: The Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

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.