CKS Practice Test 8 — 10 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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