CKS Practice Exam 3 — 20 Questions

Question 1

An administrator runs `kube-bench` and sees that the check 'Ensure that the --protect-kernel-defaults flag is set to true' has failed. Which component does this check apply to?

Accepted Answer

Kubelet. The `--protect-kernel-defaults` flag is a kubelet-specific security option that ensures the kubelet does not modify kernel parameters that could weaken node security. When set to true, it enforces that the kubelet respects kernel defaults, preventing privilege escalation via sysctl overrides. This check is part of the CIS Benchmark for the kubelet component, not for etcd, the API server, or the controller manager.

Answer

etcd

Answer

API server

Answer

Controller manager

Question 2

Which TWO actions are recommended by the CIS Kubernetes Benchmark to secure the API server?

Accepted Answer

Set --authorization-mode=RBAC. The CIS Kubernetes Benchmark recommends setting `--authorization-mode=RBAC` to enforce role-based access control, which restricts API server access based on user roles and permissions. This ensures that only authorized users and service accounts can perform specific actions, aligning with the principle of least privilege.

Answer

Set --enable-admission-plugins=NodeRestriction

Answer

Set --authorization-mode=AlwaysAllow

Answer

Set --insecure-port=8080

Question 3

What is the purpose of the 'automountServiceAccountToken: false' setting in a Pod spec?

Accepted Answer

It prevents the automatic mounting of the service account token into the pod. Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic mounting of the Kubernetes service account token (a JWT) into the Pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This is a security hardening measure to reduce the attack surface for compromised containers, as the token can be used to authenticate to the Kubernetes API server. By default, Kubernetes mounts this token into every Pod, so explicitly disabling it is necessary when the Pod does not require API access.

Answer

It disables the service account controller

Answer

It deletes the service account after the pod starts

Answer

It prevents the pod from using any service account

Question 4

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 5

Which of the following securityContext settings prevents a container from using host network namespace?

Accepted Answer

hostNetwork: false. Setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.

Answer

hostIPC: false

Answer

hostNetwork: true

Answer

hostPID: false

Question 6

An AppArmor profile is loaded in 'complain' mode. What happens when a pod with that profile attempts an action that violates the profile?

Accepted Answer

The action is allowed but a log entry is created.. In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

Answer

The pod is terminated.

Answer

The action is allowed and no log is generated.

Answer

The action is blocked and an audit log is generated.

Question 7

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?

Accepted Answer

Any pod using the default service account in kube-system has cluster-admin privileges. The ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.

Answer

The risk is only if the service account is used by external users

Answer

The ClusterRoleBinding is invalid because it uses a namespace-scoped service account

Answer

No risk, as it is limited to kube-system namespace

Question 8

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Accepted Answer

input. In Rego, `input` and `data` are reserved keywords. `input` refers to the incoming document (e.g., the admission review request in Gatekeeper), and `data` refers to the global data document containing external data. `deny` is not a keyword but a common rule name used to trigger denial; `violation` and `allow` are also custom rule names. Therefore, the correct answer is options C and D.

Answer

violation

Answer

allow

Answer

deny

Question 9

A pod with the following annotation is created: 'container.apparmor.security.beta.kubernetes.io/webserver: localhost/k8s-apparmor-profile'. However, the pod remains in 'Pending' state and the node logs show 'AppArmor not available'. What is the most likely cause?

Accepted Answer

AppArmor is not loaded or enabled on the node kernel. The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

Answer

The annotation should be on the pod's securityContext, not as an annotation

Answer

The AppArmor profile name is misspelled

Answer

The pod is using a privileged security context

Question 10

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Accepted Answer

AppArmor profiles can be loaded in 'enforce' or 'complain' mode. AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Answer

The profile name in the annotation should be just the profile name without the 'localhost/' prefix

Answer

The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

Answer

AppArmor profiles are automatically loaded from a ConfigMap

Question 11

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

Accepted Answer

Create the NetworkPolicy YAML manifest, then apply it using kubectl apply, then deploy test pods with appropriate labels, then verify connectivity using kubectl exec.. NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Answer

Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

Answer

Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

Answer

Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

Question 12

A security auditor wants to ensure that no container in the cluster has the CAP_SYS_ADMIN capability. Which of the following is the most effective way to enforce this cluster-wide?

Accepted Answer

Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods. A mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

Answer

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Answer

Modify the kubelet to disallow CAP_SYS_ADMIN

Answer

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Question 13

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

Accepted Answer

Validating webhooks should run before mutating webhooks. In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added. The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue. Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Answer

Use a validating webhook instead of ImagePolicyWebhook

Answer

The mutating webhook should be configured to skip pods with certain images

Answer

The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

Question 14

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

Accepted Answer

PSP support was removed from Kubernetes in 1.25. PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Answer

The PSP API version needs to be updated to v1

Answer

PSPs were replaced by NetworkPolicies in 1.25

Answer

The PSP was not applied to the correct namespace

Question 15

You run kube-bench on a node and it reports a failure for 'Ensure that the --anonymous-auth argument is set to false' for the kubelet service. Which file must you modify to fix this?

Accepted Answer

/var/lib/kubelet/config.yaml. Kube-bench checks the kubelet configuration for the `--anonymous-auth` flag, which is set in the kubelet's configuration file. By default, the kubelet reads its configuration from `/var/lib/kubelet/config.yaml` (or a path specified by `--config` in the kubelet service). Setting `anonymous-auth: false` in this file disables anonymous requests to the kubelet API, enforcing authentication.

Answer

/etc/kubernetes/manifests/kube-apiserver.yaml

Answer

/etc/kubernetes/pki/ca.crt

Answer

/etc/kubernetes/kubelet.conf

Question 16

Which tool can generate an SBOM for a container image?

Accepted Answer

Syft. Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) for container images and filesystems. It scans the image layers and package managers (e.g., APT, RPM, pip, npm) to produce an SBOM in formats like CycloneDX or SPDX, directly addressing the question's requirement.

Answer

Trivy

Answer

Cosign

Answer

Kubescape

Question 17

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

Accepted Answer

kubectl get pods -n kube-system kube-apiserver- -o yaml | grep anonymous-auth. The kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver- -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Answer

kubectl get --raw /api/v1

Answer

kubectl describe node | grep anonymous

Answer

kubectl cluster-info dump | grep -i anonymous

Question 18

Which kubectl command can be used to check the CIS benchmark compliance of a Kubernetes cluster?

Accepted Answer

kube-bench run --targets=master,worker. `kube-bench` is the official open-source tool from Aqua Security that runs CIS Kubernetes Benchmark checks against a cluster. It scans nodes by targeting specific roles (master, worker) and compares the cluster configuration against the CIS Benchmark controls, reporting pass/fail for each check.

Answer

kubectl security-check

Answer

kubectl cis-benchmark

Answer

kubectl audit cluster

Question 19

A security auditor recommends enabling audit logging for the Kubernetes API server with a policy that logs all requests at the Metadata level. Which configuration ensures this requirement?

Accepted Answer

Create an audit policy file with 'level: Metadata' for all resources and pass it via --audit-policy-file. Kubernetes audit logging requires an audit policy file that defines the log level for different request stages and resources. The requirement to log all requests at the Metadata level is achieved by creating a policy file with `level: Metadata` for all resources (or a catch-all rule) and passing it to the API server via the `--audit-policy-file` flag. The audit policy file is the only mechanism to specify the log level (None, Metadata, Request, RequestResponse) per resource or stage.

Answer

Enable the 'Audit' admission plugin

Answer

Set --audit-log-level=Metadata

Answer

Use --audit-log-maxage=30 to retain logs

Question 20

Match each container security context setting to its effect.

Accepted Answer

runAsNonRoot: Prevents the container from running as root. Correct matches: runAsNonRoot forces non-root execution; runAsUser sets a specific UID. Common confusion is swapping these effects. Other settings like privileged and readOnlyRootFilesystem also enforce least privilege.

Answer

runAsNonRoot: Specifies the user ID (UID) to run the container

Answer

runAsUser: Prevents the container from running as root