CKS Hard Questions — 25 Difficult Questions

Question 1

A security engineer runs kube-hunter against a production cluster and receives the above output. The cluster uses kubeadm with default settings. Which two actions should the engineer take to remediate the vulnerabilities?

Accepted Answer

Upgrade the cluster to Kubernetes 1.14 or later to fix CVE-2019-11245. Option A is correct because CVE-2019-11245 affects kubelet container runtime exec probes in Kubernetes versions prior to 1.14, where containers could restart unexpectedly due to a race condition. Upgrading to 1.14 or later patches this vulnerability. Option C is correct because setting --anonymous-auth=false on the kubelet disables unauthenticated access to the kubelet API, which is a common finding from kube-hunter when default kubeadm settings leave anonymous authentication enabled.

Answer

Set the kubelet flag --authentication-token-webhook=true

Answer

Enable the NodeRestriction admission controller

Answer

Modify the kube-apiserver manifest to set --anonymous-auth=false

Question 2

Which THREE practices help ensure the integrity and confidentiality of container logs in a Kubernetes cluster?

Accepted Answer

Configure the log collector to use TLS when shipping logs to a central system.. Option A is correct because configuring the log collector to use TLS (e.g., Fluentd with TLS output plugin or Filebeat with SSL/TLS) encrypts log data in transit, preventing eavesdropping or tampering during shipping to a central system like Elasticsearch or Splunk. This directly protects confidentiality and integrity against man-in-the-middle attacks on the network path.

Answer

Set container 'stdout' logging only, avoiding file-based logs.

Answer

Disable log rotation to prevent log tampering during rotation.

Question 3

A security auditor requires that all container images used in the cluster are scanned for vulnerabilities before deployment. The team uses a private registry with image signing. Which solution enforces that only signed and scanned images are deployed?

Accepted Answer

Use Cosign to sign images and deploy a webhook that verifies signatures.. Cosign is a tool for signing container images, and deploying a validating webhook (e.g., the cosigned admission controller) enforces that only images with valid signatures are admitted. This directly meets the requirement to deploy only signed and scanned images, as the webhook verifies the signature before the pod is created.

Answer

Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.

Answer

Use OPA Gatekeeper to verify that the image comes from the private registry.

Answer

Enable Binary Authorization on the cluster to enforce image attestation.

Question 4

You are asked to ensure that a specific Kubernetes dashboard (e.g., kubernetes-dashboard) is not publicly accessible. The dashboard is deployed in the 'kube-system' namespace. Which NetworkPolicy should you apply?

Accepted Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: []. Option B is correct because a NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{namespaceSelector: {matchLabels: {}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: kubernetes-dashboard}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Egress], egress: [{to: [{podSelector: {}}]}]

Question 5

You want to ensure that kubelets only serve pods that have been scheduled by the API server. Which admission plugin should be enabled?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the Node and Pod objects a kubelet can modify. When enabled, each kubelet can only create/modify pods bound to its own node, and only pods that have been scheduled by the API server (i.e., have a non-empty `spec.nodeName` set by the scheduler). This prevents a compromised kubelet from creating arbitrary pods or modifying pods on other nodes, enforcing that only the API server schedules pods.

Answer

ServiceAccount

Answer

AlwaysPullImages

Answer

PodNodeSelector

Question 6

Which THREE of the following are valid methods to restrict access to etcd in a Kubernetes cluster? (Select THREE)

Accepted Answer

Use TLS certificates for client and server authentication. Option A is correct because etcd supports mutual TLS (mTLS) authentication, where both the client (e.g., kube-apiserver) and the etcd server present TLS certificates to verify each other's identity. This is the standard and recommended method for securing communication between the API server and etcd, as it prevents unauthorized clients from accessing the key-value store and ensures data-in-transit encryption.

Answer

Use simple username and password authentication

Answer

Put etcd on the same network as the API server without firewall

Question 7

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

Accepted Answer

Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config. Option B is correct because etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

Answer

Use etcdctl to encrypt the data directory

Answer

Set --encryption-provider=secretbox on etcd

Answer

Set ETCD_ENABLE_ENCRYPTION=true environment variable

Question 8

Which THREE of the following are valid ways to restrict access to etcd? (Select 3)

Accepted Answer

Enable etcd RBAC to restrict read/write access. Option A is correct because etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

Answer

Use HTTP instead of HTTPS

Answer

Disable client authentication for simplicity

Question 9

You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?

Accepted Answer

--anonymous-auth=false and --authorization-mode=Webhook. Option D is correct because setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.

Answer

--anonymous-auth=false and --authorization-mode=RBAC

Answer

--anonymous-auth=true and --authorization-mode=ABAC

Answer

--anonymous-auth=false and --authorization-mode=AlwaysAllow

Question 10

An administrator wants to ensure that containers in a pod cannot run with any Linux capabilities except the minimal required for the container runtime. The pod is subject to the 'restricted' Pod Security Standard. Which capability configuration should be set in the pod's security context?

Accepted Answer

capabilities:
  drop: ["ALL"]. The 'restricted' Pod Security Standard (PSS) requires that all Linux capabilities be dropped except those essential for the container runtime (e.g., CAP_NET_BIND_SERVICE is allowed by default in some runtimes, but the standard explicitly mandates dropping all capabilities). Option A correctly uses `drop: ["ALL"]` to remove every capability, ensuring the container runs with the minimal set required by the runtime, which aligns with the PSS 'restricted' profile. This approach enforces the principle of least privilege by preventing the container from gaining any unnecessary kernel privileges.

Answer

capabilities:
  drop: ["NET_RAW", "CHOWN"]

Answer

capabilities:
  add: ["NET_BIND_SERVICE"]

Answer

capabilities:
  add: ["ALL"]

Question 11

You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?

Accepted Answer

Drop the NET_RAW capability from all containers running on the node. Option C is the least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.

Answer

Restrict SSH access to the node using firewall rules

Answer

Disable unnecessary system services (e.g., telnet, rsh) on the node

Answer

Apply the latest security patches to the host kernel

Question 12

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/: localhost/my-custom-profile. Option C is correct because the AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/` with the value `localhost/`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Answer

container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile

Answer

apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile

Answer

container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce

Question 13

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 14

A pod is configured with securityContext: { seccompProfile: { type: RuntimeDefault } }. Which of the following is true about this configuration?

Accepted Answer

The pod uses the default seccomp profile provided by the container runtime. Option D: RuntimeDefault uses the container runtime's default seccomp profile, which is typically the Docker/default profile. Option A is false; RuntimeDefault does not disable seccomp. Option B is false; it uses runtime's default, not custom. Option C is false; it does not require any special permissions.

Answer

The pod uses a custom seccomp profile

Answer

Seccomp is disabled for the pod

Answer

The pod must have CAP_SYS_ADMIN to use this setting

Question 15

Which TWO of the following are valid AppArmor profile modes? (Select 2 correct answers)

Accepted Answer

enforce. AppArmor profiles can be in enforce or complain mode. Unconfined is a state (no profile), not a mode. Profile modes are enforce, complain, and kill (not listed). Options C and D are not modes.

Answer

disabled

Answer

audit

Answer

unconfined

Question 16

A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: custom-profile.json. To use a custom seccomp profile, set type to 'Localhost' and localhostProfile to the path relative to the seccomp directory. Option A is correct. Option B uses 'RuntimeDefault' which is not custom. Option C uses 'Unconfined'. Option D is invalid.

Answer

securityContext:
  seccompProfile:
    type: Unconfined

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault
    localhostProfile: custom-profile.json

Answer

securityContext:
  seccomp:
    profile: custom-profile.json

Question 17

Which THREE of the following are best practices for reducing the attack surface of a Kubernetes node?

Accepted Answer

Run containers with non-root user and drop all capabilities. Options A, C, and D are best practices for node hardening. Option B is not a best practice because installing unnecessary packages increases attack surface. Option E is not a standard practice; SSH might be needed for admin access but should be restricted, not necessarily removed entirely.

Answer

Install all available security patches and packages

Answer

Remove SSH access from all nodes

Question 18

A cluster uses PodSecurity admission. A namespace has the label 'pod-security.kubernetes.io/enforce: baseline'. A user creates a pod that runs a container with 'privileged: true'. What happens?

Accepted Answer

The pod is rejected by the admission controller.. The baseline policy does not allow privileged containers. The admission controller will reject the pod creation.

Answer

The pod is created but flagged with a warning.

Answer

The pod is created successfully because privileged is allowed at baseline.

Answer

The pod is created but the privileged setting is ignored.

Question 19

A security auditor reports that a container can sniff network traffic on the host. Which field in the pod spec should be checked and set to false to prevent this?

Accepted Answer

hostNetwork: false. Setting 'hostNetwork: true' gives the container access to the host's network stack, allowing it to sniff traffic. Setting it to false prevents this.

Answer

hostNetwork: true

Answer

hostIPC: true

Answer

hostPID: true

Question 20

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 drops all capabilities except those required for default operation, and does not allow 'cap_add' beyond the restricted set. The correct enforcement is to use 'restricted' level with 'enforce' mode. Option A is the correct configuration. Option B uses 'baseline' which is less restrictive. Option C is incorrect because 'privileged' allows all capabilities. Option D is incorrect because 'warn' does not enforce.

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"