CKS Practice Test 18 — 15 Questions

Question 1

You need to ensure that all containers in your cluster run with a read-only root filesystem. Which field should be set in the container's security context?

Accepted Answer

readOnlyRootFilesystem: true. Setting `readOnlyRootFilesystem: true` in the container's security context mounts the container's root filesystem as read-only, preventing any writes to the root filesystem. This directly enforces the requirement that all containers run with a read-only root filesystem, which is a key supply chain security control to limit the impact of a compromised container.

Answer

allowPrivilegeEscalation: false

Answer

capabilities.drop: ['ALL']

Answer

runAsNonRoot: true

Question 2

A security engineer wants to integrate image scanning into a CI/CD pipeline. They are using a tool that can scan the filesystem of the build context before building the image. Which tool is best suited for this purpose?

Accepted Answer

Trivy (trivy fs). Trivy's `fs` subcommand scans the filesystem of a build context (directory) for vulnerabilities and misconfigurations before the container image is built. This allows the security engineer to catch issues early in the CI/CD pipeline, such as vulnerable application dependencies or insecure configurations in Dockerfiles, without needing a built image. Trivy is purpose-built for this filesystem scanning use case, making it the correct choice.

Answer

Kubesec

Answer

Notary

Answer

Cosign

Question 3

Given the following PodSecurityPolicy (PSP) snippet, which statement about the allowed containers is correct?

Accepted Answer

Containers cannot add any Linux capabilities. The PodSecurityPolicy snippet does not include `allowedCapabilities` or sets it to an empty list, and the `defaultAddCapabilities` is not specified, meaning no Linux capabilities are added by default. Additionally, the `requiredDropCapabilities` field is not present, but the absence of any allowed capabilities effectively prevents containers from adding any Linux capabilities beyond the default set, which is restricted by the PSP's `allowedCapabilities: []` or lack thereof. This enforces a strict security posture where containers cannot gain extra privileges via capabilities.

Answer

Containers can run in privileged mode

Answer

Containers cannot use ConfigMap volumes

Answer

Containers must run as the root user

Question 4

An administrator runs 'kubectl auth can-i --list --as=system:serviceaccount:ns1:my-sa' and sees that the service account has 'create pods' permission via a RoleBinding. Which command can be used to delete that RoleBinding?

Accepted Answer

kubectl delete rolebinding <binding-name> -n ns1. The `kubectl auth can-i --list` output shows that the service account `my-sa` has `create pods` permission via a RoleBinding. To remove that permission, you must delete the RoleBinding object itself, not the service account or the role (unless the role is exclusively used by this binding). Option C correctly uses `kubectl delete rolebinding` with the specific binding name and namespace to revoke the RBAC grant.

Answer

kubectl delete serviceaccount my-sa -n ns1

Answer

kubectl delete role <role-name> -n ns1

Answer

kubectl delete clusterrolebinding <binding-name>

Question 5

During a security audit, you run kube-bench and find that the API server audit logging is not enabled. Which set of flags should be added to the kube-apiserver to enable audit logging with a policy file located at /etc/kubernetes/audit-policy.yaml?

Accepted Answer

--audit-log-path=/var/log/kubernetes/audit.log --audit-policy-file=/etc/kubernetes/audit-policy.yaml. Enabling audit logging in kube-apiserver requires both `--audit-log-path` to specify the output file and `--audit-policy-file` to define the audit policy rules. Without the policy file, the API server will not know which events to log, and without the log path, no audit logs will be written.

Answer

--audit-log-maxage=30 --audit-policy-file=/etc/kubernetes/audit-policy.yaml

Answer

--audit-log-path=/var/log/kubernetes/audit.log --audit-log-maxbackup=10

Answer

--audit-log-path=/var/log/kubernetes/audit.log --audit-webhook-config-file=/etc/kubernetes/audit-policy.yaml

Question 6

Which of the following is a characteristic of Kata Containers compared to gVisor?

Accepted Answer

Kata Containers use lightweight VMs to isolate containers. Kata Containers use lightweight virtual machines (VMs) to provide strong hardware-enforced isolation for containers. Each container runs inside its own minimal VM with a separate kernel, offering security comparable to a VM while maintaining container-like performance and orchestration. This is the defining characteristic that distinguishes Kata Containers from gVisor.

Answer

Kata Containers require no additional configuration in Kubernetes

Answer

Kata Containers have lower overhead than gVisor

Answer

Kata Containers provide a user-space kernel that intercepts system calls

Question 7

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

Accepted Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "restricted"
  enforce-version: "latest". The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  warn: "restricted"
  warn-version: "latest"

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"

Answer

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "baseline"
  enforce-version: "latest"

Question 8

You are reviewing RBAC permissions and notice a ClusterRoleBinding that binds the cluster-admin role to a service account in the 'monitoring' namespace. What is the best practice recommendation?

Accepted Answer

Replace cluster-admin with a custom Role granting only necessary permissions. The principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.

Answer

Keep the binding as it is required for monitoring

Answer

Delete the service account

Answer

Change the binding to a RoleBinding in the monitoring namespace

Question 9

You are writing a Rego policy for OPA/Gatekeeper to deny pods that do not have runAsNonRoot set to true. Which Rego statement should the ConstraintTemplate contain?

Accepted Answer

violation[msg] { not input.request.object.spec.securityContext.runAsNonRoot == true }. The Rego rule `violation[msg]` is the standard pattern for Gatekeeper ConstraintTemplates to deny a resource. The condition `not input.request.object.spec.securityContext.runAsNonRoot == true` triggers a violation when the field is missing or set to false, ensuring pods do not have `runAsNonRoot` set to true. This directly enforces the requirement to deny pods without the security context.

Answer

deny[msg] { input.request.object.spec.securityContext.runAsNonRoot == true }

Answer

allow[msg] { input.request.object.spec.securityContext.runAsNonRoot == false }

Answer

deny[msg] { input.request.object.spec.containers[_].securityContext.runAsNonRoot == true }

Question 10

A pod is configured with a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. The pod manifest uses securityContext.seccompProfile with type: Localhost and localhostProfile: "custom-profile.json". The pod fails to start with an error 'seccomp profile not found'. What is the most likely cause?

Accepted Answer

The custom-profile.json file is not present on the node filesystem.. The error 'seccomp profile not found' indicates that the Kubernetes kubelet cannot locate the specified profile file on the node's filesystem. When using `type: Localhost`, the `localhostProfile` value is resolved relative to the kubelet's seccomp profile root directory (default `/var/lib/kubelet/seccomp`). If the file `custom-profile.json` does not exist at that path on the node, the pod will fail to start.

Answer

The securityContext.seccompProfile.defaultRuntimeProfile field must be set to 'custom-profile.json'.

Answer

The seccomp profile should be defined in the pod's annotations, not securityContext.

Answer

The localhostProfile field must be an absolute path.

Question 11

Which command is used to sign a container image with Cosign?

Accepted Answer

cosign sign. The `cosign sign` command is used to sign container images and other artifacts, creating a digital signature that is stored alongside the image in the registry. This signature can later be verified with `cosign verify` to ensure the image's integrity and origin. The other options serve different purposes: `cosign attest` attaches an in-toto attestation, `cosign generate` creates key pairs, and `cosign verify` checks signatures.

Answer

cosign attest

Answer

cosign generate

Answer

cosign verify

Question 12

Which of the following is a recommended CIS benchmark setting for the kubelet?

Accepted Answer

--anonymous-auth=false. The CIS benchmark for Kubernetes recommends disabling anonymous authentication on the kubelet to ensure that all requests to the kubelet API are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, preventing potential unauthorized access to node-level operations such as pod logs, exec, and port-forwarding.

Answer

--anonymous-auth=true

Answer

--protect-kernel-defaults=false

Answer

--read-only-port=10255

Question 13

A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?

Accepted Answer

Create a custom seccomp profile that allows the syscall and apply it via type: Localhost. The default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Answer

Use the RuntimeDefault profile and add capabilities

Answer

Change the seccomp profile to another runtime default

Answer

Set seccompProfile to Unconfined

Question 14

A cluster administrator wants to apply a custom seccomp profile located at '/var/lib/kubelet/seccomp/audit.json' to a pod. Which YAML snippet correctly configures the pod's security context to use this profile?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: audit.json. When using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` must specify only the filename (not the full path). Kubernetes automatically prepends the path `/var/lib/kubelet/seccomp/` to the filename, so `audit.json` resolves to the correct location.

Answer

seccompProfile:
  type: Unconfined
  localhostProfile: audit.json

Answer

seccompProfile:
  type: Localhost
  localhostProfile: /var/lib/kubelet/seccomp/audit.json

Answer

seccompProfile:
  type: RuntimeDefault
  localhostProfile: audit.json

Question 15

An administrator runs 'trivy image --severity HIGH,CRITICAL myapp:v1.0' and sees no vulnerabilities. However, a security scan of the same image using a different tool reports several HIGH severity CVEs. What is the MOST likely reason for this discrepancy?

Accepted Answer

The image was scanned with an outdated vulnerability database. Trivy relies on a local vulnerability database (e.g., the `trivy-db` or `trivy-java-db`) that must be regularly updated to include the latest CVE entries. If the database is outdated, Trivy will not detect recently published HIGH or CRITICAL vulnerabilities, even if they exist in the image. This is the most likely reason for the discrepancy, as a different tool may have a more current database.

Answer

Trivy only scans the application layer and ignores the base image

Answer

Trivy cannot scan images stored in private registries

Answer

The other tool has false positives