CKS Practice Test 44 — 15 Questions

Question 1

To reduce the attack surface, a security best practice is to drop all capabilities from a container and add only those required. Which securityContext field is used to drop all capabilities?

Accepted Answer

capabilities.drop: ["ALL"]. In Kubernetes, the `capabilities.drop` field in the securityContext is used to explicitly remove Linux capabilities from a container. Setting `capabilities.drop: ["ALL"]` drops all capabilities, effectively reducing the attack surface by ensuring the container starts with no privileges, and then specific capabilities can be added back via `capabilities.add` if needed.

Answer

capabilities.disable: ["ALL"]

Answer

capabilities.remove: ["ALL"]

Answer

privileged: false

Question 2

A DevOps engineer runs 'trivy image myapp:latest' and finds a critical CVE in the base image. Which Dockerfile change would BEST address this?

Accepted Answer

Switch to a distroless base image with a SHA digest. Switching to a distroless base image with a SHA digest (e.g., gcr.io/distroless/base@sha256:...) eliminates the vulnerable packages present in the original base image because distroless images contain only the minimal runtime dependencies (e.g., glibc, libssl) and no package manager or shell, drastically reducing the attack surface. Pinning the image by SHA digest ensures immutability and prevents the base image from being silently updated to a version that reintroduces the same or different vulnerabilities, which is critical for supply chain security.

Answer

Use an Alpine base image with the latest tag

Answer

Set USER root in the Dockerfile

Answer

Add a non-root user in the Dockerfile

Question 3

A Kyverno policy is written to require all images to use SHA256 digests instead of tags. The policy uses a 'validate' rule with 'pattern' on 'spec.containers[*].image'. Which pattern would match an image reference like 'registry.example.com/myapp@sha256:abc123...'?

Accepted Answer

"*@sha256:*". Option C ('*@sha256:*') correctly matches image references using SHA256 digest. It ensures the digest algorithm is exactly 'sha256' followed by a colon and digest. Option A ('*@sha256*') is too permissive as it matches any image reference containing 'sha256' as a substring, potentially allowing other algorithms like 'sha256-extra'. Option B ('*@*') matches any digest algorithm, not specifically SHA256. Option D ('*:*') matches tags, not digests. Therefore, only C meets the requirement.

Answer

*@sha256*

Answer

"*@*"

Answer

"*:*"

Question 4

You are using Open Policy Agent (OPA) Gatekeeper to enforce pod security. You want to create a constraint that denies pods unless they have readOnlyRootFilesystem set to true. Which Rego rule in a ConstraintTemplate correctly implements this?

Accepted Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.readOnlyRootFilesystem
  msg := "readOnlyRootFilesystem must be true"
}. It uses `not container.securityContext.readOnlyRootFilesystem` to trigger a violation when the field is missing, false, or nil. In Rego, `not` succeeds when the expression inside it fails, so this rule denies any pod where any container does not have `readOnlyRootFilesystem` explicitly set to `true`. This matches the requirement to deny pods unless the field is `true`.

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.readOnlyRootFilesystem == true
  msg := "readOnlyRootFilesystem must be true"
}

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.securityContext.readOnlyRootFilesystem == false
  msg := "readOnlyRootFilesystem must be true"
}

Answer

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.readOnlyRootFilesystem == false
  msg := "readOnlyRootFilesystem must be true"
}

Question 5

In the context of service mesh (e.g., Istio), which resource is used to enforce mutual TLS (mTLS) between services in a specific namespace?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct resource because it defines the mutual TLS (mTLS) mode for workloads within a namespace or mesh. In Istio, PeerAuthentication allows you to enforce STRICT mTLS, which requires all traffic between services in the specified namespace to use TLS certificates for both client and server authentication, preventing plaintext or unauthenticated communication.

Answer

VirtualService

Answer

DestinationRule

Answer

ServiceEntry

Question 6

You need to enforce that no pod runs with privileged containers or runs as root. Which tool can define policies that block such pods at admission time?

Accepted Answer

OPA Gatekeeper. OPA Gatekeeper is a Kubernetes admission controller that enforces custom policies defined via the Constraint Framework (CF). It can reject pods that request privileged containers or run as root by evaluating constraints against the PodSecurityPolicy-like rules expressed in Rego, blocking them before they are persisted in etcd.

Answer

Kubernetes Secret

Answer

PodDisruptionBudget

Answer

NetworkPolicy

Question 7

A security policy requires that all container images must have a signed attestation. Which Cosign command would an admin add to the CI pipeline to create this attestation?

Accepted Answer

cosign attest --type custom --predicate . The `cosign attest` command is specifically designed to create an in-toto attestation for a container image, attaching a signed predicate (e.g., a SLSA provenance file) that satisfies the policy requirement for a signed attestation. The `--type custom` flag allows specifying a custom predicate type, and `--predicate ` provides the attestation payload, which is then signed and stored in the image's OCI manifest as an attached attestation.

Answer

cosign verify-attestation <image>

Answer

cosign sign --key

Answer

cosign download attestation <image>

Question 8

A user creates a Deployment with image 'alpine:3.18' and the Pod status is 'ErrImagePull'. The admin checks the image policy and sees that only images with SHA digests are allowed. What is the fix?

Accepted Answer

Change the image to 'alpine@sha256:...'. The cluster policy requires images to be identified by SHA digest rather than tags. Using an image reference like 'alpine@sha256:...' ensures the image is pulled by its immutable digest, bypassing tag-based resolution and satisfying the policy. This is a common supply chain security measure to prevent tag mutability and ensure image integrity.

Answer

Enable the AlwaysPullImages admission controller

Answer

Change the image to 'alpine:latest'

Answer

Add a non-root user to the Dockerfile

Question 9

Which audit policy level logs the request metadata and the request body?

Accepted Answer

Request. In Kubernetes audit logging, the 'Request' level logs both the request metadata (e.g., user, timestamp, resource) and the request body (the full object sent in the API request). This level provides detailed information about the operation without including the response body, which is reserved for the 'RequestResponse' level.

Answer

None

Answer

Metadata

Answer

RequestResponse

Question 10

You are writing a Falco rule to detect when a container tries to read the file `/etc/shadow`. Which condition in the Falco rule correctly matches this event?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. Falco rules use conditions that match system calls (evt.type) and file descriptors (fd.name). The event type 'open' is the syscall used to open a file for reading, and fd.name='/etc/shadow' specifies the target file. This combination correctly detects when a container attempts to open /etc/shadow, which is the typical first step before reading it.

Answer

container.name=shadow and evt.type=open

Answer

evt.type=read and fd.name=/etc/shadow

Answer

proc.name=cat and fd.name=/etc/shadow

Question 11

Which Falco rule condition would detect an attempt to read the /etc/shadow file in a container?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. The Falco rule condition `evt.type=open and fd.name=/etc/shadow` specifically detects the `open` system call targeting the `/etc/shadow` file. Reading a file in Linux typically involves the `open` syscall (with flags like O_RDONLY) followed by `read`, but Falco's `open` event captures the initial access attempt, making it the standard way to detect file reads. This matches the requirement to detect an attempt to read `/etc/shadow` in a container.

Answer

evt.type=write and fd.name=/etc/shadow

Answer

evt.type=read and fd.name=/etc/shadow

Answer

evt.type=execve and proc.name=shadow

Question 12

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. What is the most likely reason for this state?

Accepted Answer

The pod is waiting to be scheduled to a node. A pod enters the 'Pending' state when it has been accepted by the API server but is not yet running. The most common reason is that the scheduler has not yet assigned the pod to a node, often due to insufficient resources (CPU/memory), node selector mismatches, taints/tolerations, or a failed scheduler itself. This is the initial phase before the pod transitions to 'Running' or 'ContainerCreating'.

Answer

The pod has been deleted

Answer

The container inside the pod is crashing

Answer

The pod has completed its execution

Question 13

A cluster has a ValidatingWebhookConfiguration that intercepts Pod CREATE requests. The webhook server is unavailable. What happens when a user tries to create a pod?

Accepted Answer

The pod creation is rejected until the webhook becomes available. When a ValidatingWebhookConfiguration is defined and the webhook server is unavailable, the default failure policy is `Fail`, which causes the API server to reject the Pod CREATE request. This ensures that security validation is not bypassed due to webhook downtime, maintaining the cluster's security posture. The pod creation is blocked until the webhook becomes available again, as specified by the `failurePolicy` field in the webhook configuration.

Answer

The webhook is automatically disabled

Answer

The API server crashes

Answer

The pod is created without webhook validation

Question 14

A DevOps engineer notices that a container's stdout logs are not appearing in the `kubectl logs` output. The container runs a legacy application that writes logs to a file inside the container. What is the most efficient way to capture these logs without modifying the application?

Accepted Answer

Add a sidecar container that reads the log file and outputs to stdout.. Deploying a sidecar container that tails the log file and writes to its own stdout is the most efficient, Kubernetes-native pattern for capturing logs from applications that write to files. The sidecar container shares the same Pod and volume, reads the log file (e.g., using `tail -F`), and outputs to stdout, which is then collected by `kubectl logs` and the cluster-level logging pipeline. This approach requires no modification to the legacy application and leverages the existing container runtime and kubelet log collection.

Answer

Configure the kubelet to rotate logs from the container's filesystem.

Answer

Use `kubectl cp` to periodically copy logs from the container.

Answer

Install a syslog daemon in the container to forward logs.

Question 15

A security engineer is configuring a Kubernetes cluster to meet CIS benchmark recommendations. The cluster uses kubeadm for bootstrapping. Which action should be taken to ensure the kube-apiserver is hardened against unauthorized access?

Accepted Answer

Set --anonymous-auth=false on the kube-apiserver. Setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests, ensuring that all API requests must be authenticated. This directly addresses CIS benchmark recommendations for hardening the API server against unauthorized access by preventing unauthenticated users from reaching the API.

Answer

Set --insecure-port=8080 on the kube-apiserver

Answer

Disable the NodeRestriction admission plugin

Answer

Enable encryption at rest for secrets in etcd