CKS Practice Test 12 — 15 Questions

Question 1

A security team wants to ensure that all API requests to the cluster are authenticated and uses RBAC for authorization. Which two flags must be set on the kube-apiserver?

Accepted Answer

--anonymous-auth=false --authorization-mode=RBAC. Setting --anonymous-auth=false disables unauthenticated requests, ensuring all API calls require authentication, and --authorization-mode=RBAC enforces Role-Based Access Control for authorization. This combination aligns with the security team's requirement for authenticated and RBAC-authorized API requests, as RBAC is the standard Kubernetes authorization mode for fine-grained access control.

Answer

--anonymous-auth=false --authorization-mode=Webhook

Answer

--enable-admission-plugins=NodeRestriction --authorization-mode=AlwaysAllow

Answer

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

Question 2

Which TWO of the following are required to enable encryption of Kubernetes Secrets at rest?

Accepted Answer

Create an EncryptionConfiguration resource. Option B is correct because enabling encryption at rest for Kubernetes Secrets requires creating an EncryptionConfiguration resource, a YAML file that defines the encryption providers (such as aescbc, aesgcm, or secretbox) and their key material used to encrypt resources like secrets in etcd. Option D is correct because the kube-apiserver must be started with the --encryption-provider-config flag pointing to that EncryptionConfiguration file; without this flag the API server ignores the configuration and writes Secrets to etcd in plaintext. Option A is incorrect because etcdctl is only an administrative CLI for interacting with etcd (for example, verifying that stored values are prefixed with k8s:enc:), not a mechanism for configuring encryption. Option C is incorrect because EncryptionAtRest is not a feature gate that must be enabled; the feature is controlled entirely by the --encryption-provider-config flag and the EncryptionConfiguration resource, so no such --feature-gates flag exists or is needed.

Answer

Configure etcd encryption via etcdctl

Answer

Enable the --feature-gates=EncryptionAtRest=true flag on the API server

Question 3

A pod has securityContext.readOnlyRootFilesystem: true. What happens if a process inside the container tries to write to the root filesystem?

Accepted Answer

The write will fail with an error. When `securityContext.readOnlyRootFilesystem: true` is set in a Pod spec, the container's root filesystem is mounted as read-only. Any attempt by a process inside the container to write to the root filesystem (e.g., creating a file in `/` or modifying `/etc/passwd`) will be denied by the kernel's VFS layer, and the write system call will return an error (typically `EROFS` or `EACCES`). This is enforced at the kernel level, not by Kubernetes itself.

Answer

The write will succeed because tmpfs is used

Answer

The kernel will allow the write but log it

Answer

The pod will be restarted

Question 4

Which admission plugin is recommended by the CIS Benchmark to restrict what nodes can modify?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin is recommended by the CIS Benchmark for Kubernetes to restrict what nodes can modify. It limits the Node and Pod objects a kubelet can modify, ensuring that a node can only modify its own Node object and Pods bound to it. This prevents a compromised node from affecting other nodes or pods in the cluster.

Answer

PodSecurity

Answer

AlwaysPullImages

Answer

ServiceAccount

Question 5

Which of the following is a best practice for securing container images in a Kubernetes environment?

Accepted Answer

Use minimal base images such as distroless or Alpine to reduce attack surface. Minimal base images like distroless or Alpine contain only the application and its runtime dependencies, drastically reducing the number of packages, libraries, and utilities that could contain vulnerabilities or be exploited post-compromise. Fewer components mean a smaller attack surface, faster pulls, and easier vulnerability management. This is a foundational CKS best practice for supply chain and runtime security.

Answer

Store secrets directly in the Dockerfile for convenience

Answer

Run containers as root to have full access to system resources

Answer

Use the latest tag for all base images to get the newest features

Question 6

A Kubernetes cluster has Kyverno installed. You want to enforce that all container images come from a trusted registry 'trusted-registry.example.com'. Which Kyverno policy rule type would you use?

Accepted Answer

validate with a deny condition. Kyverno's `validate` rule type with a `deny` condition is specifically designed to reject resources that violate a policy. In this case, the policy would deny any Pod that references an image not matching the pattern `trusted-registry.example.com/*`, enforcing the trusted registry requirement at admission time.

Answer

mutate

Answer

validate.deny

Answer

generate

Question 7

A ClusterRoleBinding grants cluster-admin to a service account in the 'kube-system' namespace. What is the best way to audit this for least privilege?

Accepted Answer

Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.. The cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.

Answer

Use 'kubectl auth can-i --list' to check the service account's permissions.

Answer

Delete the ClusterRoleBinding immediately.

Answer

Run 'kubectl get clusterrolebindings' to list all bindings.

Question 8

A security audit reveals that a service account 'monitor' is bound to the cluster-admin ClusterRole, which violates least-privilege. What is the best remediation?

Accepted Answer

Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding. It directly addresses the violation of least-privilege by replacing the overly permissive cluster-admin ClusterRoleBinding with a binding to a more restrictive role like 'view'. This ensures the 'monitor' service account retains only the necessary read permissions, adhering to the principle of least privilege without disrupting its functionality.

Answer

Delete the service account and recreate it without any role binding

Answer

Keep the binding but add a Deny policy for write actions

Answer

Set automountServiceAccountToken: false in the pod spec

Question 9

You need to encrypt Secrets at rest in an existing Kubernetes cluster. You create an EncryptionConfiguration file specifying aescbc as the provider. After updating the API server kube-apiserver.yaml with the new configuration, you create a new Secret. Which of the following statements is true?

Accepted Answer

Only newly created secrets will be encrypted; existing secrets remain unencrypted.. The EncryptionConfiguration only applies to data written to etcd after the API server is restarted with the new configuration. Existing Secrets that were stored in etcd before the restart remain in their original unencrypted form unless they are explicitly rewritten (e.g., by deleting and recreating them or using a tool like `kubectl get secret ... -o yaml | kubectl replace -f -`). The `aescbc` provider encrypts new data at rest, but does not retroactively encrypt existing data.

Answer

The encryption key is automatically rotated every 30 days.

Answer

The aescbc provider can be changed to identity without any impact on existing secrets.

Answer

All existing secrets in the cluster are automatically encrypted after the API server restart.

Question 10

An administrator wants to drop all capabilities for a container and then add back only NET_BIND_SERVICE. Which securityContext configuration is correct?

Accepted Answer

capabilities:
  drop: ["ALL"]
  add: ["NET_BIND_SERVICE"]. It first drops all capabilities using `drop: ["ALL"]`, which removes every Linux capability from the container, and then explicitly adds back only `NET_BIND_SERVICE`. This follows the principle of least privilege: start with no capabilities and grant only what is needed. The `securityContext` in Kubernetes applies these settings at the container level, ensuring the container can bind to privileged ports (below 1024) without any other elevated permissions.

Answer

capabilities:
  add: ["NET_BIND_SERVICE"]

Answer

capabilities:
  drop: ["ALL"]

Answer

capabilities:
  drop: ["NET_BIND_SERVICE"]
  add: ["ALL"]

Question 11

Which TWO of the following admission controllers are relevant for supply chain security in Kubernetes?

Accepted Answer

ImagePolicyWebhook. ImagePolicyWebhook (B) is correct because it is the built-in admission controller that forwards pod image decisions to an external image policy service, enabling enforcement of trusted registries, signature verification, and vulnerability policies before a workload is admitted. ValidatingAdmissionWebhook (E) is correct because policy engines such as Kyverno and OPA Gatekeeper use it to validate resources against supply chain rules, for example rejecting images that lack a valid Cosign signature or that come from unapproved registries. MutatingAdmissionWebhook (A) is not the right answer here since its typical use is sidecar injection and defaulting, not supply chain verification. AlwaysPullImages (C) only forces image pulls on every pod start to avoid stale cached images and does not verify provenance or trust. NodeRestriction (D) limits what kubelets can modify on Node and Pod objects, which is a node-security control rather than a supply chain control.

Answer

MutatingAdmissionWebhook (for sidecar injection)

Answer

AlwaysPullImages

Answer

NodeRestriction

Question 12

You want to ensure that a pod only runs on nodes that have a specific label, 'disktype=ssd'. Which field should be specified in the pod spec?

Accepted Answer

nodeSelector. C is correct because `nodeSelector` is the simplest and most direct field in a Pod spec for constraining which nodes the Pod can be scheduled on based on node labels. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only place the Pod on nodes that have that exact label key-value pair, making it the ideal choice for this straightforward label-based scheduling requirement.

Answer

affinity.nodeAffinity

Answer

nodeName

Answer

tolerations

Question 13

A security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

Accepted Answer

Restricted. The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

Answer

Privileged

Answer

Custom

Answer

Baseline

Question 14

An administrator wants to prevent a container from accessing the host's network. Which pod security context field should be set to false?

Accepted Answer

hostNetwork. The `hostNetwork` field in the Pod Security Context, when set to `true`, allows the container to use the host's network namespace directly, bypassing the pod's own network stack. Setting it to `false` (the default) ensures the container uses an isolated network namespace, preventing direct access to host network interfaces, iptables rules, and network services. This is the correct field to disable to meet the requirement of preventing container access to the host's network.

Answer

hostIPC

Answer

privileged

Answer

hostPID

Question 15

A security admin needs to audit all API requests to the Kubernetes API server. Which audit policy level logs the request body and response body?

Accepted Answer

RequestResponse. The RequestResponse audit level logs the request body and response body, along with metadata. This is the most verbose audit level, capturing the full content of API requests and responses. It is used when complete visibility into API interactions is required, such as for deep security auditing or debugging. However, it can generate large amounts of data and may expose sensitive information, so it should be used judiciously.

Answer

Request

Answer

None

Answer

Metadata