CKS Practice Test 10 — 10 Questions

Question 1

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

Accepted Answer

Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities. It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Answer

Set securityContext.capabilities.drop: ['ALL'] with no add

Answer

Leave capabilities unset to use the default set

Answer

Add only the necessary capabilities without dropping

Question 2

You are implementing a policy to ensure all containers in a namespace run as non-root. Which of the following is the most appropriate approach to enforce this at the cluster level?

Accepted Answer

Use OPA/Gatekeeper with a ConstraintTemplate that checks runAsNonRoot is set to true. OPA/Gatekeeper allows you to enforce custom policies at the cluster level via ConstraintTemplates and Constraints. By creating a ConstraintTemplate that checks `runAsNonRoot: true` in the Pod securityContext, you can ensure all Pods in a namespace (or cluster-wide) run as non-root, without modifying individual Pod specs. This approach is native to Kubernetes admission control and provides a flexible, cluster-wide enforcement mechanism.

Answer

Create a PodSecurityPolicy that requires runAsNonRoot

Answer

Set runAsNonRoot in the securityContext of each Pod spec manually

Answer

Configure a ValidatingAdmissionPolicy with a CEL rule requiring runAsNonRoot

Question 3

Which admission plugin should be enabled on the kube-apiserver to restrict kubelet permissions and prevent nodes from modifying their own Node objects?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the kubelet's permissions to only modify labels, annotations, and status on its own Node object, preventing a compromised or misconfigured node from altering other Node objects or escalating privileges. This is a critical hardening measure for cluster setup, as it enforces the principle of least privilege on kubelet API access.

Answer

ServiceAccount

Answer

AlwaysPullImages

Answer

PodSecurityPolicy

Question 4

A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?

Accepted Answer

Modify the ClusterRoleBinding to use a less privileged role. The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Answer

Disable the service account token automount

Answer

Delete the service account

Answer

Set --authorization-mode=AlwaysDeny

Question 5

You are tasked with ensuring that all container images in your cluster are scanned for vulnerabilities before being deployed. You have set up Trivy in your CI/CD pipeline and want to enforce that only images with no critical vulnerabilities are allowed. Which admission controller should you configure to reject pods using non-compliant images?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend (e.g., Trivy) before they are admitted into the cluster. It intercepts pod creation requests, sends the image reference to an external webhook for validation, and rejects pods whose images contain critical vulnerabilities. This makes it the correct choice for enforcing image vulnerability policies at admission time.

Answer

ValidatingAdmissionWebhook

Answer

PodSecurityPolicy (PSP)

Answer

ResourceQuota

Question 6

A cluster administrator wants to ensure that a specific service account (my-sa) cannot have its token mounted automatically in pods. Which setting should be applied to the service account?

Accepted Answer

automountServiceAccountToken: false. Setting `automountServiceAccountToken: false` in the ServiceAccount spec prevents pods that use that service account from automatically mounting its token. Note that this is a spec field, not an annotation; the question's wording is slightly misleading. Options A and C are incorrect because they use string values or wrong syntax. Option D is incorrect because the annotation `kubernetes.io/enforce-mountable-secrets` does not exist in Kubernetes.

Answer

automountServiceAccountToken: "false"

Answer

mount-token: "false"

Answer

kubernetes.io/enforce-mountable-secrets: "true"

Question 7

Which admission plugin should be enabled to prevent kubelets from modifying nodes or pods they do not own?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin ensures that kubelets can only modify the Node and Pod objects they are assigned to. It enforces that a kubelet with a specific node identity can only label, taint, or update its own Node object and can only create/modify Pods that are bound to that node. This prevents a compromised or misconfigured kubelet from tampering with other nodes or pods in the cluster.

Answer

AlwaysPullImages

Answer

PodSecurity

Answer

ServiceAccount

Question 8

A DevOps team deploys a microservice that needs to access a third-party API using credentials stored in a Kubernetes Secret. The team wants to minimize the risk of credential exposure. Which approach best achieves this goal while following security best practices?

Accepted Answer

Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.. Mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.

Answer

Store the credentials in a Secret and mount it as a volume with default permissions.

Answer

Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.

Answer

Store the credentials in a ConfigMap and inject them as environment variables.

Question 9

A developer creates a Deployment with the following container spec:

```yaml
containers:
- name: app
  image: myapp:latest
  env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password
```

Which of the following is a security concern with this approach?

Accepted Answer

The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.. Injecting secrets as environment variables exposes them in the container's process environment, which can be read from /proc/self/environ or /proc/1/environ by any process running in the container. If the container is compromised, an attacker can easily extract the secret from the environment, and it may also leak into logs or error messages. Kubernetes secrets should be mounted as files (e.g., via volumes) to reduce exposure, as environment variables are more accessible to malicious code.

Answer

The secret is not encrypted at rest in etcd.

Answer

The secret name 'db-secret' is too generic.

Answer

The secret is not base64 encoded.

Question 10

You are a security engineer for a financial services company running a Kubernetes cluster on-premises. The cluster uses kubeadm for bootstrapping and Calico for network policy. Recently, a compliance audit revealed that all nodes in the cluster have the kubelet port 10250 open to the public network, allowing unauthenticated access to the kubelet API. This poses a severe security risk. The cluster has 10 worker nodes and 3 control plane nodes. You need to remediate this without disrupting running workloads. The nodes are behind a corporate firewall, but the internal network is considered untrusted. You have access to the node's iptables and can modify configuration files. Which course of action best secures the kubelet port while maintaining cluster functionality?

Accepted Answer

Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).. Using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.

Answer

Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.

Answer

Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.

Answer

Set the --anonymous-auth flag to false on each kubelet and restart them one by one.