CKS Practice Test 42 — 15 Questions

Question 1

Which two of the following are recommended by the CIS Kubernetes Benchmark? (Choose two.)

Accepted Answer

Disable anonymous authentication on the API server. The CIS Kubernetes Benchmark explicitly recommends disabling anonymous authentication on the API server to prevent unauthenticated access. Anonymous requests bypass all authentication checks and can lead to unauthorized cluster operations if RBAC is not properly scoped. Setting the `--anonymous-auth=false` flag on the API server ensures that only authenticated users can interact with the cluster.

Answer

Use NodePort services for internal communication

Answer

Enable the insecure port on the API server

Answer

Use the default service account for all pods

Question 2

You run 'crictl ps' and see no output, but the node has running pods. What is the most likely cause?

Accepted Answer

The --runtime-endpoint flag is not set or points to the wrong socket. The `crictl ps` command queries the container runtime via the CRI (Container Runtime Interface) socket. If it returns no output while the node clearly has running pods (visible via `kubectl` or `kubelet`), the most likely cause is that the `--runtime-endpoint` flag is not set or points to the wrong socket. By default, `crictl` uses `/var/run/dockershim.sock` (deprecated) or may fall back to an incorrect path; if the actual runtime socket (e.g., `/run/containerd/containerd.sock` for containerd, or `/var/run/crio/crio.sock` for CRI-O) is not specified, the tool cannot connect to the runtime and returns an empty list.

Answer

The container runtime is not Docker

Answer

The pod uses a different container runtime than CRI-O

Answer

The containers are in a different namespace

Question 3

A security policy requires that all container images must reference a specific SHA256 digest instead of a tag. You need to enforce this using Kyverno. Which Kyverno rule type and pattern would you use?

Accepted Answer

A validate rule with a pattern that the image field matches '@sha256:'. Kyverno's validate rules with a pattern can enforce that the image field in a Pod spec contains '@sha256:', ensuring only digest-based references are used. This directly meets the security policy requirement without altering the image reference or relying on external data.

Answer

A generate rule that creates a ConfigMap with allowed digests

Answer

A mutate rule that replaces the image tag with a digest

Answer

A validate rule checking the annotation 'image.openshift.io/triggers'

Question 4

You are a Kubernetes administrator for a fintech company that runs a payment processing service in a production cluster. The service consists of multiple microservices that communicate over the network. Recently, a security audit revealed that a compromised pod could potentially send malicious requests to other services because there are no network restrictions between pods. The security team has mandated that all inter-service traffic must be encrypted and authenticated, and that only necessary traffic should be allowed. You need to implement a solution that meets these requirements with minimal changes to the application code and minimal operational overhead. Which approach should you take?

Accepted Answer

Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.. Deploying Istio as a service mesh with mutual TLS (mTLS) provides transparent encryption and authentication of all inter-service traffic without modifying application code. Istio's AuthorizationPolicy resources allow fine-grained, label-based access control to enforce the principle of least privilege, meeting the security mandate with minimal operational overhead through sidecar proxy injection.

Answer

Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.

Answer

Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.

Answer

Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.

Question 5

Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)

Accepted Answer

proc.pname. Option C (proc.pname) is correct because it identifies the parent process name, so a rule can match when the parent is a shell or entrypoint such as bash, sh, or a container runtime, indicating a shell was spawned by another process. Option E (proc.name) is correct because it identifies the name of the process that was executed, allowing detection of the spawned shell itself, e.g., proc.name=bash or proc.name=sh. Together, proc.pname and proc.name let Falco express conditions like proc.name in (bash, sh) and proc.pname in (bash, sh, docker, containerd) to catch shells spawned inside containers. Option A (evt.type) only describes the syscall event type (e.g., execve, clone) and does not by itself identify a shell process. Option B (k8s.ns.name) only scopes the event to a Kubernetes namespace and provides no process-level information. Option D (container.id) merely identifies the container in which the event occurred, not that a shell was spawned.

Answer

evt.type

Answer

k8s.ns.name

Answer

container.id

Question 6

An administrator needs to enforce the restricted Pod Security Standard on a namespace 'secure-ns'. Which kubectl command should they use?

Accepted Answer

kubectl label namespace secure-ns pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards (PSS) are enforced via labels on namespaces, using the key `pod-security.kubernetes.io/enforce` with the value `restricted`. This instructs the built-in Pod Security Admission controller to reject any pod that violates the restricted profile in the `secure-ns` namespace.

Answer

kubectl label namespace secure-ns security=restricted

Answer

kubectl create podsecuritypolicy restricted -n secure-ns

Answer

kubectl annotate namespace secure-ns pod-security.kubernetes.io/enforce=restricted

Question 7

Which flag enables the PodSecurity admission plugin in kube-apiserver?

Accepted Answer

--enable-admission-plugins=PodSecurity. The PodSecurity admission plugin is enabled in kube-apiserver by passing the `--enable-admission-plugins=PodSecurity` flag. This flag activates the built-in Pod Security Admission (PSA) controller, which replaced the deprecated PodSecurityPolicy (PSP) in Kubernetes v1.25. The plugin enforces the Pod Security Standards (baseline, restricted, privileged) at the namespace level based on labels.

Answer

--admission-control=PodSecurity

Answer

--feature-gates=PodSecurity=true

Answer

--pod-security-policy=true

Question 8

An administrator wants to restrict a service account to only be able to create pods in the 'development' namespace. Which RBAC configuration should be used?

Accepted Answer

Create a Role in the 'development' namespace and a RoleBinding that binds the service account to that Role.. A Role is namespace-scoped and can only grant permissions within the namespace where it is created. By creating a Role in the 'development' namespace and binding the service account to it via a RoleBinding, the service account is restricted to creating pods only in that namespace, as required.

Answer

Create a Role in the default namespace and a RoleBinding that binds the service account to that Role.

Answer

Create a ClusterRole and a ClusterRoleBinding that binds the service account to that ClusterRole.

Answer

Create a ClusterRole and a RoleBinding in the 'development' namespace.

Question 9

Which flag on the kubelet disables anonymous access?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth` flag on the kubelet controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous access, requiring all requests to present valid authentication credentials. This is a critical hardening measure to prevent unauthenticated users from interacting with the kubelet API.

Answer

--disable-anonymous

Answer

--no-anonymous

Answer

--enable-anonymous-auth=false

Question 10

Which audit stage in Kubernetes audit logging captures the stage after a request is processed and before a response is sent?

Accepted Answer

ResponseStarted. The `ResponseStarted` audit stage in Kubernetes audit logging captures the stage after a request has been processed by the API server but before the response is sent to the client. This stage allows logging of the response headers and status code while the response body is still being streamed, providing visibility into the server-side processing outcome before the client receives the full payload.

Answer

ResponseComplete

Answer

Panic

Answer

RequestReceived

Question 11

A developer creates a Dockerfile with 'FROM ubuntu:latest'. The security team recommends using a minimal base image. Which change minimizes the attack surface?

Accepted Answer

FROM gcr.io/distroless/base:latest. The `gcr.io/distroless/base:latest` image is a minimal, language-specific base image that contains only the essential runtime dependencies (e.g., glibc, libssl) and no package manager, shell, or utilities. This drastically reduces the attack surface by eliminating unnecessary binaries and tools that could be exploited. In contrast, `ubuntu:latest` includes a full userland with apt, bash, and other utilities, increasing the potential for privilege escalation or supply chain attacks.

Answer

FROM alpine:latest

Answer

FROM scratch

Answer

FROM ubuntu:20.04

Question 12

Which Kyverno policy action is used to automatically mutate a resource to add a sidecar container for security?

Accepted Answer

mutate. The `mutate` action in Kyverno is specifically designed to modify incoming Kubernetes resources before they are persisted. Adding a sidecar container (e.g., a security agent like Istio or Falco) is a classic mutation use case, where the policy patches the Pod spec to inject the container definition. This is distinct from validation, image verification, or resource generation.

Answer

validate

Answer

verifyImages

Answer

generate

Question 13

A pod runs with an immutable root filesystem (readOnlyRootFilesystem: true). The application attempts to write to /tmp. What is the expected behavior?

Accepted Answer

The write fails with a permission error unless a writable volume is mounted at /tmp. When a pod is configured with `readOnlyRootFilesystem: true`, the container's root filesystem is mounted as read-only. The `/tmp` directory is part of the root filesystem, so any write attempt to it will fail with a permission error (EPERM) unless a writable volume (e.g., `emptyDir`, `hostPath`, or `PersistentVolumeClaim`) is explicitly mounted at `/tmp`. This is enforced by the Linux kernel's mount flags and is a common security hardening practice to prevent unauthorized writes.

Answer

The application can write to any directory because /tmp is always writable

Answer

The container crashes immediately

Answer

The write succeeds and is silently dropped

Question 14

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

Accepted Answer

The container runs as user 1001. When `runAsNonRoot: true` is set, Kubernetes enforces that the container cannot run as root (UID 0). However, the pod also specifies `runAsUser: 1001`, which tells Kubernetes to run the container as UID 1001. Since UID 1001 is non-root, the `runAsNonRoot` constraint is satisfied. The container image's expectation to run as root is irrelevant because Kubernetes overrides the user with the specified `runAsUser`. Therefore, the container will start and run as user 1001.

Answer

The container runs as root because runAsUser overrides runAsNonRoot

Answer

The container fails to start because it cannot run as root

Answer

The pod runs, but the securityContext is ignored

Question 15

Which of the following is a static analysis tool for Kubernetes manifests?

Accepted Answer

Kubesec. Kubesec is a static analysis tool specifically designed to evaluate Kubernetes manifests against a set of security best practices. It parses YAML or JSON resource definitions and scores them based on pod security contexts, container privilege escalation, and other runtime hardening rules, without executing the manifests.

Answer

Cosign

Answer

Trivy

Answer

Syft