CKS Practice Test 36 — 15 Questions

Question 1

You are configuring etcd encryption at rest. After placing the EncryptionConfiguration YAML file, you must modify which file to point the API server to it?

Accepted Answer

/etc/kubernetes/manifests/kube-apiserver.yaml. The API server is deployed as a static pod in a typical Kubernetes cluster, with its manifest located at /etc/kubernetes/manifests/kube-apiserver.yaml. To enable encryption at rest, you must add the `--encryption-provider-config` flag to this manifest, pointing to the EncryptionConfiguration YAML file. The kubelet automatically detects the change and restarts the API server pod to apply the new encryption configuration.

Answer

/etc/kubernetes/admin.conf

Answer

/etc/kubernetes/pki/etcd/ca.crt

Answer

/etc/kubernetes/kubelet.conf

Question 2

Which TWO of the following are valid audit stages in Kubernetes? (Select 2)

Accepted Answer

ResponseStarted. `ResponseStarted` is a valid Kubernetes audit stage that occurs when the audit handler starts sending the response to the client. This stage is part of the audit event lifecycle defined in the Kubernetes API server, capturing the moment the response headers are sent but before the body is fully transmitted.

Answer

RequestEvaluated

Answer

All of the above

Answer

ResponseSent

Question 3

A pod runs with a service account that has a ClusterRoleBinding granting cluster-admin. What is the best practice to reduce the risk of privilege escalation?

Accepted Answer

Create a more restrictive Role/ClusterRole with only required permissions and bind it to the service account, removing the cluster-admin binding. The principle of least privilege dictates that a service account should only have the permissions necessary for its function. By creating a more restrictive Role/ClusterRole with only required permissions and binding it to the service account, you remove the excessive cluster-admin privileges, directly reducing the risk of privilege escalation. This aligns with Kubernetes RBAC best practices for hardening cluster setup.

Answer

Use a PodSecurityPolicy to restrict the service account

Answer

Delete the service account and create a new one without any roles

Answer

Add a NetworkPolicy to block outbound traffic from the pod

Question 4

You run 'trivy image myapp:latest' and the scan reports several critical CVEs. What is the best action to take?

Accepted Answer

Rebuild the image with updated base images and re-deploy. Rebuilding the image with updated base images directly addresses the root cause of the CVEs—outdated or vulnerable packages in the container image. After rebuilding, you must re-deploy the updated image to replace the running vulnerable containers. This aligns with the supply chain security principle of maintaining a secure software bill of materials (SBOM) and ensuring images are patched against known vulnerabilities before deployment.

Answer

Use kubectl delete pod to remove the running container

Answer

Delete the image from the registry

Answer

Ignore the CVEs because the image is running in a non-production environment

Question 5

Which THREE options are valid methods to secure etcd in a Kubernetes cluster?

Accepted Answer

Enable TLS with peer and client certificates. Enabling TLS with peer and client certificates encrypts all communication between etcd members and between etcd and the Kubernetes API server, preventing man-in-the-middle attacks and unauthorized access. This is a fundamental security requirement for etcd in production clusters, as etcd stores all cluster state and secrets.

Answer

Set --auto-compaction-mode=periodic

Answer

Enable RBAC authorization in etcd

Question 6

A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?

Accepted Answer

capabilities.drop: ["ALL"] capabilities.add: ["NET_BIND_SERVICE"]. It drops all Linux capabilities using `capabilities.drop: ["ALL"]` and then explicitly adds only the necessary `NET_BIND_SERVICE` capability via `capabilities.add: ["NET_BIND_SERVICE"]`. This adheres to the principle of least privilege by starting from a clean slate and granting only the required capability. In Kubernetes security contexts, the correct keys are `capabilities.drop` and `capabilities.add` under the `securityContext` field. Options B and D partially meet the requirement but do not drop all capabilities; Option C adds all capabilities, violating the policy.

Answer

cap_drop: ["NET_RAW"]

Answer

cap_add: ["ALL"]

Answer

cap_add: ["NET_BIND_SERVICE"]

Question 7

Which TWO of the following are recommended CIS Kubernetes Benchmark controls for securing the kube-apiserver?

Accepted Answer

Disable anonymous authentication. The CIS Kubernetes Benchmark recommends disabling anonymous authentication to ensure that all requests to the kube-apiserver are authenticated. This prevents unauthenticated users from accessing the API server, which is a critical security control. Option D is correct because enabling audit logging is a recommended control to record all API requests, providing an audit trail for security monitoring and incident response.

Answer

Enable insecure port 8080

Answer

Set --authorization-mode to AlwaysAllow

Answer

Disable TLS

Question 8

You need to detect any attempt to run a shell inside a container using Falco. Which macro or condition should you use?

Accepted Answer

evt.type=execve and proc.name in (bash, sh). Detecting a shell inside a container requires monitoring the execution of shell binaries. Falco's `evt.type=execve` captures process execution events, and `proc.name in (bash, sh)` filters for common shell programs. This combination directly identifies when a shell process is started, which is a strong indicator of interactive access or potential compromise.

Answer

evt.type=read and fd.name=/etc/passwd

Answer

evt.type=clone and proc.name=bash

Answer

evt.type=open and fd.name=/bin/bash

Question 9

A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: "custom-profile.json". When using a custom seccomp profile stored in the default kubelet seccomp directory (`/var/lib/kubelet/seccomp/`), the `type` must be `Localhost` and the `localhostProfile` must be a relative path (just the filename). Kubernetes automatically prepends the default seccomp root path, so `custom-profile.json` resolves to `/var/lib/kubelet/seccomp/custom-profile.json`.

Answer

seccompProfile:
  type: Unconfined
  localhostProfile: "custom-profile.json"

Answer

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

Answer

seccompProfile:
  type: Localhost
  localhostProfile: "/var/lib/kubelet/seccomp/custom-profile.json"

Question 10

An admin wants to check which AppArmor profiles are loaded. Which command should they run?

Accepted Answer

aa-status. The `aa-status` command is the standard tool for displaying the status of AppArmor, including which profiles are loaded, their enforcement mode (enforce/complain), and process confinement. It queries the AppArmor security module directly via the kernel interface, making it the correct and most comprehensive command for this task.

Answer

apparmor list

Answer

seccomp-status

Answer

ls /sys/kernel/security/apparmor/profiles

Question 11

An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?

Accepted Answer

The node was cordoned using 'kubectl cordon '. The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon ', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.

Answer

The kubelet is not running

Answer

The node has insufficient resources

Answer

The node is tainted with NoSchedule

Question 12

Which THREE of the following are valid flags for the 'trivy image' command to output results in different formats?

Accepted Answer

--format table. The `trivy image` command supports multiple output formats via the `--format` flag. The valid formats include `table`, `sarif`, and `json`, which are explicitly documented in Trivy's CLI help. `table` produces a human-readable summary, `sarif` outputs results in the SARIF (Static Analysis Results Interchange Format) standard, and `json` provides structured data for programmatic consumption.

Answer

--format xml

Answer

--format yaml

Question 13

You need to create a ClusterRole that allows listing secrets, but only in namespaces that have a specific label 'security-level=high'. Which approach should you use?

Accepted Answer

Create a ClusterRole and bind it with RoleBindings in each labeled namespace. ClusterRoleBindings grant permissions cluster-wide, but RoleBindings can bind a ClusterRole to subjects within specific namespaces. By creating a ClusterRole with the necessary rules (e.g., 'list secrets') and then creating RoleBindings only in namespaces that have the label 'security-level=high', you effectively restrict the permission to those namespaces. This approach leverages the fact that a ClusterRole can be used with RoleBindings to scope permissions to individual namespaces.

Answer

Create a Role in each namespace, then aggregate them into a ClusterRole

Answer

Create a ClusterRole and bind it with a ClusterRoleBinding; add a namespace condition in the role

Answer

Create a ClusterRole with a namespaceSelector: matchLabels: security-level: high

Question 14

Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)

Accepted Answer

Using the seccomp.security.alpha.kubernetes.io/pod annotation. The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.

Answer

Setting securityContext.seLinuxOptions.type

Answer

Using the container.apparmor.security.beta.kubernetes.io annotation

Answer

Using the seccomp.security.beta.kubernetes.io/pod annotation

Question 15

You need to create a NetworkPolicy that allows only ingress traffic from pods with label 'app: frontend' in the same namespace. Which policyType and ingress rule should you use?

Accepted Answer

policyTypes: [Ingress]
ingress:
- from:
  - podSelector:
      matchLabels:
        app: frontend. A NetworkPolicy that restricts ingress traffic to only pods with the label 'app: frontend' in the same namespace must use `policyTypes: [Ingress]` and an `ingress` rule with a `podSelector` that matches that label. The `podSelector` without a `namespaceSelector` implicitly selects pods only within the same namespace as the NetworkPolicy, which satisfies the requirement.

Answer

policyTypes: [Ingress]
ingress:
- from:
  - podSelector: {}

Answer

policyTypes: [Ingress]
ingress:
- from:
  - namespaceSelector: {}

Answer

policyTypes: [Egress]