CKS Practice Test 32 — 15 Questions

Question 1

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 2

Which of the following is the best practice for injecting secrets into a pod?

Accepted Answer

Injecting via volume mounts. Mounting secrets as volumes ensures that secret data is stored in the pod's filesystem as files, which are created in a tmpfs in-memory filesystem (ram-backed) and never written to disk. This approach also allows for automatic rotation of secret values when the Secret object is updated, without requiring a pod restart, and avoids exposing secrets in process listings or container logs.

Answer

Storing secrets in container image layers

Answer

Using environment variables

Answer

Using ConfigMap for secrets

Question 3

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 4

You are a security engineer at a company running a Kubernetes cluster in production. The cluster uses containerd as the container runtime and has been configured with Node Authorizer and NodeRestriction admission controller. Recently, a security audit revealed that several pods running as root have been compromised via container escape vulnerabilities. The audit report recommends hardening the nodes to reduce the attack surface. Specifically, you need to ensure that even if an attacker gains root access inside a container, they cannot execute privileged operations on the host node, such as loading kernel modules, modifying host network settings, or accessing host devices. The cluster runs on Ubuntu 20.04 nodes with Linux kernel 5.4. You have access to modify node-level configurations but must minimize performance impact and avoid breaking existing workloads that rely on standard Linux capabilities. Which of the following actions would most effectively mitigate these risks?

Accepted Answer

Configure containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.. Seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.

Answer

Enable user namespaces for all containers by setting the 'hostUsers: false' option in the pod spec, which maps container root to a non-root user on the host.

Answer

Remove the CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities from all containers by setting a default PodSecurityPolicy that drops these capabilities.

Answer

Enable AppArmor on all nodes and apply a custom profile that denies all mount and network-related system calls.

Question 5

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 6

Which Kubernetes admission controller ensures that a pod only uses images from a specific registry?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller allows you to define a webhook that validates container images against a policy, such as restricting them to a specific registry. When a pod is created, Kubernetes sends an admission review to the webhook, which can reject images not from the allowed registry. This is the correct choice because it directly enforces image source policies.

Answer

NamespaceLifecycle

Answer

PodNodeSelector

Answer

AlwaysPullImages

Question 7

Which THREE of the following are best practices for minimizing host access from containers to reduce the attack surface? (Select three.)

Accepted Answer

Avoid setting hostPID to true. Setting hostPID to true allows a container to share the host's process ID namespace, enabling it to see all host processes and potentially access sensitive information or perform privilege escalation. Avoiding this setting reduces the attack surface by preventing containers from interacting with host-level processes, which is a key principle of namespace isolation in Kubernetes.

Answer

Disable swap on nodes

Answer

Avoid using hostPort in container port mappings

Question 8

A DevOps team wants to enforce that all Deployments must have a specific label 'app.kubernetes.io/name'. Which tool can be used to validate this in the admission controller stage?

Accepted Answer

Kyverno. Kyverno is a Kubernetes-native policy engine that can validate, mutate, and generate resources using admission webhooks. It can enforce that all Deployments carry the label 'app.kubernetes.io/name' by defining a 'validate' rule in a ClusterPolicy, which checks the resource during the admission controller stage before it is persisted to etcd.

Answer

Trivy

Answer

Cosign

Answer

Syft

Question 9

An organization uses Kyverno to enforce policies. Which Kyverno rule action would you use to require that all images come from a specific registry?

Accepted Answer

validate. The `validate` action in Kyverno is used to enforce policies that check resource attributes against specified rules. To require that all images come from a specific registry, you would use a `validate` rule with a pattern or deny clause that inspects the image field (e.g., `spec.containers[*].image`) and rejects any that do not match the allowed registry prefix. This ensures non-compliant resources are blocked at admission time.

Answer

verifyImages

Answer

generate

Answer

mutate

Question 10

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

Accepted Answer

RuntimeClass with handler: runsc. To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Answer

DaemonSet to install gVisor on nodes

Answer

PodSecurityPolicy with gVisor enabled

Answer

SecurityContext with runtime: gvisor

Question 11

You are managing a Kubernetes cluster that hosts multiple microservices. The cluster uses Kubernetes v1.25. Recently, a security audit identified that containers are running with the default seccomp profile (unconfined). The security team has requested that all containers use a seccomp profile that blocks unnecessary syscalls. You need to implement this cluster-wide without breaking existing applications. The audit also found that the kubelet's anonymous authentication is enabled, which should be disabled. Additionally, you need to ensure that the kubelet's NodeRestriction admission controller is enabled to limit what nodes can do. Which of the following is the most appropriate sequence of actions?

Accepted Answer

First, configure the kubelet to use a seccomp profile that logs violations (e.g., 'runtime/default' with log), then after verifying no breakage, switch to 'runtime/default'. Then disable anonymous authentication and enable NodeRestriction admission controller. It follows the principle of least disruption: first, it applies the 'runtime/default' seccomp profile in logging mode to detect any blocked syscalls without breaking applications. After verifying no breakage, it switches to enforcing mode. Then, it disables anonymous authentication and enables the NodeRestriction admission controller, both of which are non-disruptive configuration changes. This sequence minimizes risk to existing workloads while meeting all audit requirements.

Answer

Disable anonymous authentication immediately, then enable NodeRestriction, and finally apply the restrictive seccomp profile

Answer

Apply the 'runtime/default' seccomp profile cluster-wide immediately, then disable anonymous auth, and finally enable NodeRestriction

Answer

Enable NodeRestriction first, then apply a restrictive seccomp profile, and last disable anonymous authentication

Question 12

A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?

Accepted Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode. The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

Answer

Use a mutating admission webhook to automatically add seccomp profiles

Answer

Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode

Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode

Question 13

Which TWO of the following are recommended practices for securing the Kubernetes API server? (Select TWO)

Accepted Answer

Enable audit logging.. Enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Answer

Set --cors-allowed-origins=* for easy access.

Answer

Disable TLS to improve performance.

Answer

Set --insecure-port=8080 to allow non-TLS access.

Question 14

Which of the following host access settings should be avoided to minimize the attack surface from containers? (Select the setting that increases risk the most.)

Accepted Answer

hostPID: true. Setting `hostPID: true` allows a container to share the host's process ID namespace, enabling it to see all processes running on the host. This breaks the fundamental isolation that containers should provide, giving a compromised container direct visibility into host processes and the ability to potentially interact with them (e.g., sending signals). This significantly increases the attack surface and is the most dangerous setting among the options.

Answer

securityContext:
  capabilities:
    drop: ["ALL"]

Answer

readOnlyRootFilesystem: true

Answer

resources:
  limits:
    memory: "512Mi"

Question 15

A pod is running with a custom seccomp profile located at /var/lib/kubelet/seccomp/my-profile.json. Which securityContext configuration correctly applies this profile?

Accepted Answer

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

Answer

seccompProfile: { type: RuntimeDefault }

Answer

seccompProfile: { type: Localhost, localhostProfile: /var/lib/kubelet/seccomp/my-profile.json }

Answer

seccompProfile: { type: Unconfined }