CKS Practice Test 24 — 15 Questions

Question 1

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

Accepted Answer

kubectl get pods -n kube-system kube-apiserver- -o yaml | grep anonymous-auth. The kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver- -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Answer

kubectl get --raw /api/v1

Answer

kubectl describe node | grep anonymous

Answer

kubectl cluster-info dump | grep -i anonymous

Question 2

Which admission plugin should be enabled on the API server to ensure that the kubelet cannot modify its own Node object beyond its assigned node?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin is specifically designed to limit the kubelet's ability to modify its own Node object. It ensures that a kubelet can only label, taint, or update the status of its assigned Node, preventing it from impersonating other nodes or escalating privileges. This is the correct plugin for enforcing node-scoped kubelet permissions. Options A, B, and C are irrelevant to this requirement.

Answer

PodSecurityPolicy

Answer

AlwaysPullImages

Answer

ServiceAccount

Question 3

Falco detects a shell being opened inside a container. Which Falco rule field is used to specify the syscall condition for detection?

Accepted Answer

condition. In Falco, the `condition` field within a rule defines the specific syscall or event filter that triggers the rule. For detecting a shell being opened inside a container, the condition would include a syscall like `execve` or `clone` combined with container context filters such as `container.id != host`. This field is where you specify the exact syscall and its parameters (e.g., `evt.type=execve and proc.name in (bash, sh, zsh)`), making it the correct answer.

Answer

priority

Answer

output

Answer

rule

Question 4

Which ONE of the following is a valid method to restrict a container's filesystem to read-only in Kubernetes?

Accepted Answer

Set readOnlyRootFilesystem: true in the container's securityContext. The only valid method listed. Setting `readOnlyRootFilesystem: true` in the container's securityContext directly makes the container's root filesystem read-only. Options A, B, and D only make specific volumes read-only (ConfigMap, hostPath, emptyDir), but do not prevent writes to the container's own filesystem (e.g., /etc, /tmp, /var). Therefore, only option C correctly restricts the container's filesystem to read-only.

Answer

Use a ConfigMap volume with defaultMode 0444

Answer

Set readOnly: true on a hostPath volume mount

Answer

Mount an emptyDir volume with readOnly: true

Question 5

You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?

Accepted Answer

Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace. OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.

Answer

Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem

Answer

Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext

Answer

Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding

Question 6

A cluster administrator wants to enforce that containers run with a read-only root filesystem. Which security context field should be set?

Accepted Answer

readOnlyRootFilesystem: true. The `readOnlyRootFilesystem: true` field in the Pod or container security context explicitly mounts the container's root filesystem as read-only, preventing any writes to the filesystem. This is a key runtime security control to mitigate malware or unauthorized modifications, as required by the CIS Kubernetes Benchmark and common security policies.

Answer

privileged: false

Answer

readOnly: true

Answer

allowPrivilegeEscalation: false

Question 7

You want to isolate a compromised pod by blocking all network traffic to and from it. Which NetworkPolicy would you apply?

Accepted Answer

A policy with podSelector matching the pod, and policyTypes: [Ingress, Egress] with no rules. To isolate a compromised pod by blocking all network traffic, you need a NetworkPolicy that selects the pod and denies both ingress and egress. A policy with podSelector matching the pod and policyTypes: [Ingress, Egress] with no rules will deny all ingress and egress traffic because an empty rule set means no traffic is allowed. This effectively isolates the pod.

Answer

A policy with podSelector matching the pod, and only ingress rules denying from all

Answer

A policy with podSelector matching the pod, and egress rules allowing to 0.0.0.0/0

Answer

A policy with podSelector: {} and no rules

Question 8

You have enabled etcd encryption at rest using an EncryptionConfiguration with aescbc provider. After applying the configuration, you create a new Secret. Which of the following is true regarding the encrypted Secret?

Accepted Answer

Only the new Secret is encrypted; existing Secrets remain in plaintext.. When you apply an EncryptionConfiguration with aescbc provider, only newly created Secrets are encrypted at rest. Existing Secrets remain in plaintext because encryption is applied at write time; the API server does not retroactively re-encrypt data already stored in etcd. This is why option C is correct.

Answer

All Secrets are encrypted because the EncryptionConfiguration applies to all resources.

Answer

All Secrets in the cluster, including existing ones, are immediately encrypted.

Answer

The new Secret is stored in plaintext because aescbc is not a valid provider.

Question 9

A ClusterRole named 'secret-reader' is defined with rules to get, list, and watch secrets. A RoleBinding in namespace 'app' binds this ClusterRole to a service account. Which of the following best describes the permissions of the service account?

Accepted Answer

The service account can get, list, and watch secrets only in the 'app' namespace.. A RoleBinding in a specific namespace grants the permissions defined in the referenced ClusterRole, but only within that namespace. Since the RoleBinding is in the 'app' namespace, the service account receives the get, list, and watch permissions for secrets only within the 'app' namespace, not cluster-wide. This is the standard behavior of RoleBinding when binding to a ClusterRole.

Answer

The service account has no permissions because ClusterRole cannot be used with RoleBinding.

Answer

The service account can only get secrets in the 'app' namespace.

Answer

The service account can get, list, and watch secrets in all namespaces.

Question 10

Which TWO of the following are valid Rego keywords used in OPA policies for Gatekeeper? (Select TWO)

Accepted Answer

input. In Rego, `input` and `data` are reserved keywords. `input` refers to the incoming document (e.g., the admission review request in Gatekeeper), and `data` refers to the global data document containing external data. `deny` is not a keyword but a common rule name used to trigger denial; `violation` and `allow` are also custom rule names. Therefore, the correct answer is options C and D.

Answer

violation

Answer

allow

Answer

deny

Question 11

A security auditor wants to verify that the AppArmor profile 'my-profile' is in enforce mode on a running container. Which command should they run inside the node?

Accepted Answer

cat /proc//attr/current. The file `/proc//attr/current` contains the current AppArmor confinement status for a given process. Reading this file for a container's PID inside the node will show the profile name and mode (e.g., `my-profile (enforce)`), directly confirming that the profile is in enforce mode.

Answer

dmesg | grep apparmor

Answer

apparmor_parser -r my-profile

Answer

cat /proc/<pid>/environ

Question 12

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Accepted Answer

AppArmor profiles can be loaded in 'enforce' or 'complain' mode. AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Answer

The profile name in the annotation should be just the profile name without the 'localhost/' prefix

Answer

The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

Answer

AppArmor profiles are automatically loaded from a ConfigMap

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

An incident responder needs to isolate a compromised pod immediately without deleting it. Which action should they take?

Accepted Answer

Apply a NetworkPolicy that denies all traffic to and from the pod's labels. Applying a NetworkPolicy that denies all ingress and egress traffic to the pod's labels is the correct isolation action because it preserves the pod for forensic analysis while cutting off all network communication. Kubernetes NetworkPolicy operates at the pod-selector level, so a default-deny policy targeting the compromised pod's labels immediately blocks both inbound and outbound traffic without touching the pod's lifecycle. This satisfies the incident responder's requirement to isolate without deleting, keeping volatile memory and container state intact for investigation.

Answer

Modify the pod's labels to prevent it from receiving traffic

Answer

Delete the pod to stop its activity

Answer

Scale down the deployment to zero replicas

Question 15

During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes?

Accepted Answer

kubectl exec -- ps aux. `kubectl exec -- ps aux` runs the `ps aux` command inside the container, which lists running processes. It is the only kubectl command that allows you to inspect container processes. Options A, C, and D do not provide process listings.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

kubectl describe pod <pod-name>