CKS Practice Test 11 — 15 Questions

Question 1

Which command is used to sign a container image with Cosign and store the signature in an OCI registry?

Accepted Answer

cosign sign --key cosign.key myimage:latest. `cosign sign --key cosign.key myimage:latest` is the standard Cosign command to sign a container image using a private key and store the resulting signature in the OCI registry as an attached artifact (e.g., a `.sig` layer). This command generates a signature that is automatically pushed to the same registry alongside the image, enabling verification without external storage.

Answer

cosign docker-sign myimage:latest

Answer

cosign verify --key cosign.pub myimage:latest

Answer

cosign attach signature --key cosign.key myimage:latest

Question 2

You are using crictl to debug a container. Which command lists all running containers on the node?

Accepted Answer

crictl ps. `crictl ps` is the command used to list running containers on a node when using the CRI (Container Runtime Interface) compatible runtimes like containerd or CRI-O. It mirrors the Docker `docker ps` syntax and shows only running containers by default, which is exactly what the question asks for.

Answer

crictl containers

Answer

crictl get pods

Answer

crictl list

Question 3

An admin runs 'kubectl get pod web -o yaml' and sees the following security context. Which setting prevents privilege escalation?

Accepted Answer

allowPrivilegeEscalation: false. `allowPrivilegeEscalation: false` directly prevents a process from gaining more privileges than its parent process, such as through setuid binaries or gaining root capabilities. This setting is enforced by the kernel via the `no_new_privs` flag, which blocks privilege escalation attempts regardless of other security context settings.

Answer

Both B and C

Answer

runAsNonRoot: true

Answer

capabilities: drop: [ALL]

Question 4

You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?

Accepted Answer

rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]. It defines an audit policy rule that matches requests to the `secrets` resource (core API group, empty string) in the `kube-system` namespace and sets the audit level to `RequestResponse`, which logs both the request metadata and the response body. The subsequent `- level: Metadata` rule acts as a catch-all for all other requests, logging only metadata. Audit policy rules are evaluated in order, and the first matching rule applies, so the specific rule for secrets must come before the general rule.

Answer

rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]

Answer

rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]

Answer

rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]

Question 5

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor provides exactly two operational modes for a profile: enforce (option A) and complain (option B). In enforce mode, the profile's rules are actively applied and any access that violates the policy is denied and logged, which is the default mode for loaded profiles. In complain mode, violations are not blocked but are instead logged as complaints, allowing administrators to test and refine a profile before enforcing it. The other options are not AppArmor modes: audit (C) is not a mode but rather a logging facility/flag, allow (D) is not an AppArmor mode (it resembles SELinux terminology or a policy rule action), and unconfined (E) describes a process with no profile attached, not a selectable profile mode.

Answer

audit

Answer

allow

Answer

unconfined

Question 6

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

Accepted Answer

Restart the kube-apiserver with --encryption-provider-config flag. The EncryptionConfiguration resource defines how Kubernetes should encrypt data at rest, but it is not automatically applied. The kube-apiserver must be restarted with the `--encryption-provider-config` flag pointing to the configuration file so that it reads and enforces the encryption settings for all subsequent writes to etcd. Without this flag, the apiserver ignores the EncryptionConfiguration entirely.

Answer

Apply the EncryptionConfiguration as a ConfigMap

Answer

Restart the kube-scheduler

Answer

Recreate all secrets in the cluster

Question 7

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

Accepted Answer

Run a vulnerability scan on the container image. Running a vulnerability scan on the container image (Option A) is the most effective step because it directly checks the image layers and installed packages against known Common Vulnerabilities and Exposures (CVEs) databases, such as the National Vulnerability Database (NVD). This identifies security flaws in base images and dependencies before deployment, which is a core requirement of supply chain security in Kubernetes.

Answer

Check the image size

Answer

Run unit tests on the application code

Answer

Lint the Dockerfile

Question 8

Which of the following is a recommended CIS Benchmark control for etcd?

Accepted Answer

Enable TLS for etcd peer and client communication. The CIS Benchmark for etcd recommends enabling TLS for both peer and client communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd datastore, which is critical for Kubernetes cluster state integrity.

Answer

Use HTTP for client communication

Answer

Disable audit logging

Answer

Enable anonymous authentication

Question 9

What is the purpose of the --audit-policy-file flag on the kube-apiserver?

Accepted Answer

To specify the audit policy configuration. The `--audit-policy-file` flag on the kube-apiserver specifies the path to a YAML or JSON file that defines the audit policy configuration. This policy determines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). It does not directly enable audit logging or set the log file location; it only provides the rules for filtering and structuring audit events.

Answer

To specify the location of the audit log file

Answer

To enable audit logging

Answer

To configure the retention of audit logs

Question 10

You need to preserve evidence (container logs) from a compromised pod before deleting it. Which command should you run first?

Accepted Answer

kubectl logs <pod> --tail=-1 > pod.log. `kubectl logs --tail=-1` retrieves the complete log history (all lines) from the container's stdout/stderr stream, which is the primary source of container logs in Kubernetes. Redirecting this output to a file preserves the evidence before the pod is deleted, ensuring the logs are not lost when the pod is removed.

Answer

kubectl exec <pod> -- cat /var/log/*

Answer

kubectl cp <pod>:/var/log ./pod-logs

Answer

kubectl delete pod <pod>

Question 11

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Accepted Answer

Ensure containers run with a non-root user.. Running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Answer

Manually inject sidecar proxies into every pod to enforce mTLS.

Answer

Run containers in privileged mode to allow them to perform necessary system calls.

Answer

Store secrets directly in container images for easy access.

Question 12

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

Accepted Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`. The goal is to deny any Pod whose containers do not explicitly set runAsNonRoot to true. In Rego, the deny rule must fire when the condition is violated, so the correct expression is `input.review.object.spec.containers[_].securityContext.runAsNonRoot != true`. This matches containers that either omit the field or set it to false, which is exactly the insecure state the admin wants to block. The Constraint then binds this template to Pods via match.kinds.

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Question 13

A cluster administrator wants to enforce the Pod Security Standard 'restricted' at the namespace level. Which command applies the PodSecurity admission label to the 'prod' namespace?

Accepted Answer

kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted. The `enforce` label is the only one that actively blocks pods that violate the specified Pod Security Standard (PSS) level. The command `kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted` applies the 'restricted' policy at the namespace level, causing the PodSecurity admission controller to reject any pod that does not comply with the restricted profile.

Answer

kubectl label namespace prod pod-security.kubernetes.io/warn=restricted

Answer

kubectl label namespace prod pod-security.kubernetes.io/audit=restricted

Answer

kubectl annotate namespace prod security.kubernetes.io/pod-security=restricted

Question 14

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

Accepted Answer

Store the API key in a Kubernetes Secret and mount it as a volume inside the container. Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Answer

Store the API key in a ConfigMap and expose it as an environment variable

Answer

Hardcode the API key in the container image

Answer

Store the API key in a Kubernetes Secret and expose it as an environment variable

Question 15

You run 'crictl ps' and see a container with state CONTAINER_RUNNING. What does this indicate?

Accepted Answer

The container is running normally. In crictl, the state CONTAINER_RUNNING indicates that the container's processes are actively executing and the container is in a normal operational state. This corresponds to the container runtime (e.g., containerd) reporting the container as fully started and not in any transitional or halted state.

Answer

The container has exited

Answer

The container is paused

Answer

The container is starting up