CKS Practice Test 3 — 30 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

Which crictl command can you use to view the logs of a specific container?

Accepted Answer

crictl logs <container-id>. `crictl logs` is the dedicated command to retrieve and display the logs of a specific container managed by a CRI-compatible runtime (e.g., containerd, CRI-O). It works similarly to `docker logs` and reads the container's stdout/stderr streams, which are captured by the container runtime.

Answer

crictl inspect <container-id>

Answer

crictl exec <container-id> cat /var/log/syslog

Answer

crictl ps

Question 3

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Accepted Answer

Use Kyverno policy engine. Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Answer

Run kube-bench on the cluster

Answer

Manual review of all pod specs

Question 4

Which kubelet flag should be set to ensure the kubelet does not allow anonymous requests?

Accepted Answer

--anonymous-auth=false. Setting `--anonymous-auth=false` explicitly disables anonymous requests to the kubelet. By default, anonymous authentication is enabled, which allows unauthenticated users to access the kubelet API. Disabling this flag ensures that only authenticated requests are processed, aligning with the principle of least privilege and hardening the cluster.

Answer

--authentication-token-webhook=true

Answer

--read-only-port=0

Answer

--protect-kernel-defaults=true

Question 5

Which TWO of the following flags are used to secure the kubelet?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` flag is used to secure the kubelet by ensuring that kernel tunable parameters (e.g., `vm.overcommit_memory`, `kernel.panic`) are set to safe values. If the kernel defaults are not properly configured, the kubelet will fail to start, preventing insecure kernel settings from being used. This flag is part of the kubelet's security hardening measures, as recommended by the CIS Kubernetes Benchmark.

Answer

--enable-admission-plugins

Answer

--audit-log-path

Answer

--authorization-mode=RBAC

Question 6

A security auditor runs kube-bench and reports that the kubelet is not configured with --protect-kernel-defaults. What is the impact of this misconfiguration?

Accepted Answer

Kernel parameters may be modified, potentially reducing node security. The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter hardening, preventing modifications that could weaken node security. Without it, a compromised or misconfigured pod could alter kernel settings (e.g., `net.ipv4.ip_forward`, `vm.overcommit_memory`), reducing the overall security posture of the node. This does not affect image pulling, pod scheduling, or kubelet startup.

Answer

Container runtime will not be able to pull images

Answer

The node will be unable to schedule pods

Answer

The kubelet will refuse to start

Question 7

Which Pod Security Standard level allows the use of hostNetwork, hostPID, and hostIPC?

Accepted Answer

Privileged. The Privileged Pod Security Standard (PSS) level is the most permissive, allowing unrestricted access to host-level resources, including hostNetwork, hostPID, and hostIPC. These settings grant the pod direct access to the host's network namespace, process table, and inter-process communication mechanisms, which are explicitly prohibited in the Baseline and Restricted levels. The Privileged level is designed for system-level workloads that require such elevated permissions, such as CNI plugins or monitoring agents.

Answer

None of the above

Answer

Baseline

Answer

Restricted

Question 8

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 9

You need to run kube-bench on a control plane node. Which command should you use?

Accepted Answer

kube-bench run --targets=master. `kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

Answer

kube-bench run --targets=controlplane

Answer

kube-bench run --targets=node

Answer

kube-bench run --targets=etcd

Question 10

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Answer

--read-only-port=0

Answer

--anonymous-auth=false

Answer

--kubelet-extra-args

Question 11

Which TWO of the following are best practices for securing secrets in Kubernetes?

Accepted Answer

Enabling encryption at rest for secrets. Kubernetes stores secrets in etcd by default without encryption. Enabling encryption at rest (via the EncryptionConfiguration resource with a provider like AES-CBC or KMS) ensures that secret data is encrypted before being written to etcd, protecting it from unauthorized access to the underlying storage. This is a fundamental security control required for compliance and defense-in-depth.

Answer

Storing secrets as environment variables

Answer

Using the default secret type (Opaque) for all secrets

Answer

Limiting the number of secrets in the cluster

Question 12

You are securing a cluster and want to ensure that service account tokens are not automatically mounted in pods that do not need them. Which THREE actions should you take?

Accepted Answer

Set automountServiceAccountToken: false in the service account definition for service accounts that do not need tokens. Setting `automountServiceAccountToken: false` in the service account definition prevents the automatic mounting of the service account token into any pod that uses that service account. This is a declarative, scalable approach to disable token mounting for all pods associated with that service account, aligning with the principle of least privilege.

Answer

Set --service-account-lookup=false on the API server

Answer

Delete all service accounts except those used by system components

Question 13

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 14

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Accepted Answer

Mount Kubernetes Secrets as volumes into the pod.. Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Answer

Use environment variables from the pod spec referencing Secret keys.

Answer

Pass secrets as command-line arguments to the container.

Answer

Store secrets in ConfigMaps with base64 encoded data.

Question 15

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

Accepted Answer

cosign sign . The `cosign sign ` command is used to sign a container image by attaching a digital signature to the image manifest in the container registry. This signature, typically stored as a separate tag or in an OCI artifact, allows verification of the image's origin and integrity using the corresponding public key.

Answer

cosign verify <image>

Answer

cosign attest <image>

Answer

cosign generate <image>

Question 16

Which TWO of the following are valid methods to verify the integrity of a container image in a Kubernetes supply chain? (Select 2)

Accepted Answer

Signing the image with Cosign and verifying the signature before deployment. Cosign is a tool for signing container images using cryptographic keys, and verifying the signature before deployment ensures that the image has not been tampered with since it was signed. This provides integrity and authenticity in the software supply chain, as the signature can be validated against a trusted public key or a keyless identity (e.g., via Fulcio).

Answer

Running the container in a separate namespace

Answer

Scanning the image for vulnerabilities using Trivy

Answer

Using a base image with the latest tag

Question 17

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Answer

PodSecurityPolicy (deprecated)

Answer

ResourceQuota

Answer

ValidatingAdmissionPolicy

Question 18

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 19

You are asked to generate an SBOM for a container image and attach it as an attestation using cosign. Which two commands would you run in sequence?

Accepted Answer

syft myimage:latest -o spdx > sbom.spdx && cosign attest --type spdx --predicate sbom.spdx myimage:latest. It first uses Syft to generate an SPDX-format SBOM from the container image, then uses cosign attest to attach that SBOM as an in-toto attestation to the image. This sequence satisfies the requirement to generate an SBOM and attach it as an attestation using cosign.

Answer

trivy image --format spdx myimage:latest > sbom.spdx && cosign verify --key cosign.pub myimage:latest

Answer

cosign sign --key cosign.key myimage:latest && syft myimage:latest -o spdx

Answer

crane ls myimage:latest && cosign attest --type spdx --predicate sbom.spdx myimage:latest

Question 20

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor has two operational modes: 'enforce' and 'complain'. In 'enforce' mode, AppArmor actively enforces the security policy, blocking actions that violate the profile and logging the denial. In 'complain' mode, AppArmor logs policy violations but does not block them, allowing administrators to test profiles before enforcing them.

Answer

audit

Answer

allow

Answer

unconfined