CKS Practice Test 3 — 30 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

Question 11

Which TWO of the following are valid AppArmor profile modes? (Select two.)

Accepted Answer

Complain. AppArmor profiles operate in two primary modes: 'Complain' (also known as 'learning' mode) and 'Enforce' (the default mode). In Complain mode, policy violations are logged but not blocked, which is useful for testing and developing profiles. In Enforce mode, violations are both logged and blocked, actively enforcing the security policy. Options C (Complain) and D (Enforce) are correct.

Answer

Audit

Answer

Disabled

Answer

Unconfined

Question 12

Which TWO of the following are valid methods to apply a seccomp profile to a pod in Kubernetes?

Accepted Answer

Setting 'securityContext.seccompProfile.type' in the pod spec. The `securityContext.seccompProfile.type` field in the pod spec is the current, stable method to apply a seccomp profile to a pod in Kubernetes (since v1.19). This field directly specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`) at the container or pod level, and is the recommended approach in modern clusters.

Answer

Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'

Answer

Including 'seccomp' profile in PodSecurityPolicy

Answer

Including 'seccompProfile' under 'spec.securityContext' at the pod level

Question 13

An administrator wants to enforce a custom AppArmor profile named 'k8s-apparmor-example' on a pod. The profile has been loaded on the node. Which annotation should be added to the pod's metadata to apply this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example. The annotation format for applying an AppArmor profile to a container in a pod is `container.apparmor.security.beta.kubernetes.io/<container_name>`. The value `localhost/k8s-apparmor-example` specifies that the profile named `k8s-apparmor-example` is loaded locally on the node. This annotation enforces the profile on the container named 'nginx'.

Answer

container.apparmor.security.beta.kubernetes.io/pod: localhost/k8s-apparmor-example

Answer

apparmor.security.beta.kubernetes.io/pod: k8s-apparmor-example

Answer

container.apparmor.security.beta.kubernetes.io/nginx: k8s-apparmor-example

Question 14

A DevOps engineer wants to enforce that all container images running in the cluster are signed using Cosign. Which Kubernetes admission controller is designed for this purpose?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to enforce that container images meet certain criteria, such as being signed with Cosign, by querying an external webhook service that validates image signatures before admitting a pod. It intercepts pod creation requests and checks the image references against a configured policy, making it the correct choice for this Cosign-based image signing enforcement scenario.

Answer

MutatingAdmissionWebhook

Answer

PodSecurityPolicy (deprecated)

Answer

ValidatingAdmissionWebhook

Question 15

A security engineer runs kube-hunter against a production cluster and receives the above output. The cluster uses kubeadm with default settings. Which two actions should the engineer take to remediate the vulnerabilities?

Accepted Answer

Upgrade the cluster to Kubernetes 1.14 or later to fix CVE-2019-11245. CVE-2019-11245 affects kubelet container runtime exec probes in Kubernetes versions prior to 1.14, where containers could restart unexpectedly due to a race condition. Upgrading to 1.14 or later patches this vulnerability. Option C is correct because setting --anonymous-auth=false on the kubelet disables unauthenticated access to the kubelet API, which is a common finding from kube-hunter when default kubeadm settings leave anonymous authentication enabled.

Answer

Set the kubelet flag --authentication-token-webhook=true

Answer

Enable the NodeRestriction admission controller

Answer

Modify the kube-apiserver manifest to set --anonymous-auth=false

Question 16

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

Accepted Answer

PeerAuthentication with mTLS mode set to STRICT. PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls configuration

Answer

ServiceEntry with mTLS enabled

Question 17

A pod is in a CrashLoopBackOff state. You run 'kubectl logs pod-name' and see: 'Error: failed to start container: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the /app executable. The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Answer

The pod is out of memory

Answer

The container's working directory is incorrect

Answer

The pod has a liveness probe that is failing

Question 18

Which of the following is a best practice when writing a Dockerfile for a containerized application?

Accepted Answer

Use a minimal base image such as distroless or alpine. Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.

Answer

Run the application as the root user for file permissions

Answer

Hardcode credentials in the Dockerfile for convenience

Answer

Use the latest tag for the base image to get the newest features

Question 19

An administrator runs kube-bench on a node and sees a warning about the kubelet anonymous authentication being enabled. Which kubelet flag should be set to disable anonymous access?

Accepted Answer

--anonymous-auth=false. The kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Answer

--anonymous-auth=true

Answer

--enable-anonymous=false

Answer

--disable-anonymous=true

Question 20

Which of the following is a best practice for storing sensitive information like database passwords in Kubernetes?

Accepted Answer

Mount secrets as volumes in the pod. Mounting secrets as volumes ensures that sensitive data is stored in the in-memory tmpfs filesystem, which is never written to disk and is automatically removed when the pod is deleted. This approach also allows for automatic updates of secret values when the Secret object is modified, without requiring a pod restart, and provides better access control through filesystem permissions.

Answer

Use environment variables in the pod spec to pass secrets

Answer

Embed secrets as literals in the pod YAML file

Answer

Store them in ConfigMaps