CKS Practice Test 7 — 10 Questions

Question 1

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

Accepted Answer

Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config. Kubernetes encrypts secrets at rest by defining an EncryptionConfiguration object that specifies which encryption providers (e.g., AES-CBC, secretbox, or KMS) to use, and then passing the configuration file to the kube-apiserver via the `--encryption-provider-config` flag. This ensures that when the API server writes secrets to etcd, they are encrypted before storage, and decrypted on read, meeting the requirement for encrypting secrets at rest.

Answer

Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager

Answer

Use a MutatingWebhookConfiguration to encrypt secrets before storage

Answer

Enable the 'SecretEncryption' feature gate on all control plane components

Question 2

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

Accepted Answer

Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.. Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Answer

Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.

Answer

Scan the base image before building the application image.

Answer

Manually review vulnerability reports after the image is deployed.

Question 3

Which ONE of the following is a valid method to restrict a container's filesystem to read-only in Kubernetes?

Accepted Answer

Set readOnlyRootFilesystem: true in the container's securityContext. The only valid method listed. Setting `readOnlyRootFilesystem: true` in the container's securityContext directly makes the container's root filesystem read-only. Options A, B, and D only make specific volumes read-only (ConfigMap, hostPath, emptyDir), but do not prevent writes to the container's own filesystem (e.g., /etc, /tmp, /var). Therefore, only option C correctly restricts the container's filesystem to read-only.

Answer

Use a ConfigMap volume with defaultMode 0444

Answer

Set readOnly: true on a hostPath volume mount

Answer

Mount an emptyDir volume with readOnly: true

Question 4

A team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?

Accepted Answer

Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes. It follows the Kubernetes best practice of using a mutating admission webhook to inject a sidecar container (e.g., Vault Agent or Bank-Vaults) that authenticates with HashiCorp Vault, fetches secrets, and mounts them as volumes into the pod. This approach avoids storing secrets in etcd (as ConfigMaps or environment variables do) and eliminates the need for manual secret injection, aligning with the principle of least privilege and dynamic secret management.

Answer

Use a ConfigMap to mount secrets as files

Answer

Store secrets as environment variables in the pod spec

Answer

Use kubectl exec to copy secrets into the container at startup

Question 5

During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes?

Accepted Answer

kubectl exec -- ps aux. `kubectl exec -- ps aux` runs the `ps aux` command inside the container, which lists running processes. It is the only kubectl command that allows you to inspect container processes. Options A, C, and D do not provide process listings.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

kubectl describe pod <pod-name>

Question 6

You need to configure Kubernetes audit logging to log all requests to the 'secrets' API. Which audit policy level captures the body of the request?

Accepted Answer

Request. The 'Request' audit level logs the request metadata and the request body, which includes the body of the request. This is exactly what the question asks for. 'RequestResponse' adds the response body, which is not required per the question. Therefore, the correct answer is A.

Answer

None

Answer

RequestResponse

Answer

Metadata

Question 7

An administrator wants to enable audit logging on the API server. Which three flags are required to set up basic audit logging?

Accepted Answer

--audit-log-maxage=30. For basic audit logging in Kubernetes, three flags are required: `--audit-log-path` specifies the file path for audit logs, `--audit-policy-file` defines the policy controlling which events are logged, and `--audit-log-maxage` sets the retention period in days. These ensure logging is enabled, filtered, and rotated. The `--audit-log-format` flag is optional because JSON is the default, and `--audit-log-maxbackup` and `--audit-log-maxsize` can be added but are not required for basic setup.

Answer

--audit-log-format=json

Question 8

Which tool can be used to generate an SBOM (Software Bill of Materials) for a container image?

Accepted Answer

syft. Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to catalog packages (e.g., APK, DEB, RPM, Python, Java) and outputs the SBOM in formats like SPDX or CycloneDX, which are industry standards for supply chain transparency. This makes it the correct choice for generating an SBOM from a container image in a CKS context.

Answer

trivy

Answer

kubesec

Answer

checkov

Question 9

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

Accepted Answer

EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1. 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.

Answer

EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1

Answer

EncryptionConfig with apiVersion v1

Answer

SecretEncryption with apiVersion v1

Question 10

A pod is running with AppArmor enabled using a profile named 'k8s-apparmor-profile'. You want to verify that the profile is loaded and set to enforce mode. Which command should you run on the node?

Accepted Answer

aa-status. `aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

Answer

aa-profile --status

Answer

aa-enabled

Answer

cat /sys/kernel/security/apparmor/profiles