CKS Practice Test 48 — 15 Questions

Question 1

A Falco rule has priority: CRITICAL and condition: evt.type=execve and proc.name!=bash. What does this rule detect?

Accepted Answer

All execve events except bash regardless of namespace. The Falco rule `evt.type=execve and proc.name!=bash` with priority CRITICAL detects all `execve` system call events where the process name is NOT `bash`. Falco operates at the host level and monitors all system calls across the entire node, including those from containers. Since the rule does not include a container-specific filter (e.g., `container.id != host`), it applies to all processes regardless of namespace. Therefore, the rule detects all execve events except bash on the entire node—both host and container processes. Option B correctly captures this scope ('regardless of namespace').

Answer

Any process spawning bash

Answer

All execve events inside containers except bash

Answer

All execve events on the host except bash

Question 2

In a CI/CD pipeline, at which stage should container image scanning be performed?

Accepted Answer

After building the image but before pushing to registry. Container image scanning should be performed after building the image but before pushing it to the registry (Option D). This ensures that vulnerabilities are detected before the image is stored and distributed, preventing insecure images from being deployed. Scanning at this stage integrates security into the CI/CD pipeline, allowing teams to fail the build or trigger remediation before the image reaches production.

Answer

Only when a vulnerability is reported

Answer

After deployment to production

Answer

Before code commit

Question 3

A security policy requires that all communication to etcd be encrypted. Which two components must be configured with TLS certificates to achieve this? (Select two)

Accepted Answer

kube-apiserver. The kube-apiserver is the only control plane component that directly communicates with etcd. To encrypt this communication, TLS certificates must be configured on both the kube-apiserver (as client) and etcd (as server). The other components (kubelet, kube-scheduler, kube-controller-manager) do not directly interact with etcd, so they do not need etcd-specific TLS configuration.

Answer

kubelet

Answer

kube-scheduler

Answer

kube-controller-manager

Question 4

A security audit reveals that several pods have the service account token mounted automatically. Which setting should be configured on the pod's service account to prevent automatic mounting?

Accepted Answer

Set 'automountServiceAccountToken: false' in the service account definition.. Setting `automountServiceAccountToken: false` in the service account definition prevents pods that use that service account from automatically mounting the service account token. This is the recommended way to disable automatic token mounting at the service account level, as per Kubernetes security best practices.

Answer

Set 'automountServiceAccountToken: true' in the pod spec.

Answer

Add annotation 'seccomp.security.alpha.kubernetes.io/pod: "runtime/default"' to the service account.

Answer

Add annotation 'kubernetes.io/enforce-mountable-secrets: "false"' to the service account.

Question 5

A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?

Accepted Answer

Modify the ClusterRoleBinding to use a less privileged role. The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Answer

Disable the service account token automount

Answer

Delete the service account

Answer

Set --authorization-mode=AlwaysDeny

Question 6

You are tasked with ensuring that all container images in your cluster are scanned for vulnerabilities before being deployed. You have set up Trivy in your CI/CD pipeline and want to enforce that only images with no critical vulnerabilities are allowed. Which admission controller should you configure to reject pods using non-compliant images?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend (e.g., Trivy) before they are admitted into the cluster. It intercepts pod creation requests, sends the image reference to an external webhook for validation, and rejects pods whose images contain critical vulnerabilities. This makes it the correct choice for enforcing image vulnerability policies at admission time.

Answer

ValidatingAdmissionWebhook

Answer

PodSecurityPolicy (PSP)

Answer

ResourceQuota

Question 7

After deploying a pod with an AppArmor profile, the pod status shows 'ContainerCreating' for a long time and then fails. What is the most likely cause?

Accepted Answer

The AppArmor profile is not loaded on the node. When a pod remains in 'ContainerCreating' state and then fails, it often indicates that the node cannot apply the specified AppArmor profile. The most likely cause is that the profile referenced in the pod annotation (e.g., 'container.apparmor.security.beta.kubernetes.io/: localhost/') is not loaded into the node's kernel. Without the profile loaded, the container runtime (e.g., containerd or CRI-O) cannot enforce the policy, causing the pod creation to hang and eventually fail.

Answer

The AppArmor profile is not in the same namespace as the pod

Answer

The pod's securityContext does not have 'apparmor: enabled'

Answer

The node does not support AppArmor

Question 8

Which TWO of the following are valid audit stages in Kubernetes? (Choose two.)

Accepted Answer

ResponseComplete. In Kubernetes auditing, the audit policy defines stages that determine at which points in the request lifecycle an audit event is recorded. Option B, ResponseComplete, is a valid stage that logs an event after the API server has finished sending the response to the client, capturing the final outcome. Option C, RequestReceived, is a valid stage that logs an event as soon as the API server receives the request, before any processing occurs. The other options are not valid Kubernetes audit stages: ResponseFull, RequestProcessing, and RequestComplete do not exist in the audit.k8s.io API; the actual stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic.

Answer

ResponseFull

Answer

RequestProcessing

Answer

RequestComplete

Question 9

Which Kubernetes resource should be used to restrict egress traffic from pods?

Accepted Answer

NetworkPolicy with egress rules. NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Answer

PodSecurityPolicy

Answer

iptables rules on nodes

Answer

NetworkPolicy with ingress rules

Question 10

A cluster administrator wants to ensure that a specific service account (my-sa) cannot have its token mounted automatically in pods. Which setting should be applied to the service account?

Accepted Answer

automountServiceAccountToken: false. Setting `automountServiceAccountToken: false` in the ServiceAccount spec prevents pods that use that service account from automatically mounting its token. Note that this is a spec field, not an annotation; the question's wording is slightly misleading. Options A and C are incorrect because they use string values or wrong syntax. Option D is incorrect because the annotation `kubernetes.io/enforce-mountable-secrets` does not exist in Kubernetes.

Answer

automountServiceAccountToken: "false"

Answer

mount-token: "false"

Answer

kubernetes.io/enforce-mountable-secrets: "true"

Question 11

A security engineer wants to ensure that all container images in a Kubernetes cluster have a non-root user. Which admission controller can enforce this requirement?

Accepted Answer

Kyverno. Kyverno is a Kubernetes-native policy engine that can enforce custom admission control rules, such as requiring containers to run as a non-root user. Unlike deprecated or built-in controllers, Kyverno allows you to define fine-grained policies (e.g., `autogen-check`) that validate or mutate Pod specs to ensure `runAsNonRoot: true` or `runAsUser: >0`.

Answer

ServiceAccount

Answer

PodSecurityPolicy (deprecated)

Answer

NodeRestriction

Question 12

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. Setting `seccompProfile.type: RuntimeDefault` in the pod's securityContext instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile, which is typically a restrictive profile that blocks a large set of syscalls. This is the recommended approach for enabling seccomp without needing to define a custom profile, and it is available in Kubernetes v1.19+.

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 13

Which THREE of the following are valid encryption providers that can be used in EncryptionConfiguration for encryption at rest?

Accepted Answer

aescbc. (aescbc) is correct because AES-CBC is a symmetric encryption algorithm that Kubernetes supports natively in EncryptionConfiguration for encrypting Secrets at rest. It uses a 32-byte key for AES-256 encryption and is the most commonly used provider for this purpose.

Answer

aesgcm

Answer

rsa

Question 14

Which admission plugin should be enabled to prevent kubelets from modifying nodes or pods they do not own?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin ensures that kubelets can only modify the Node and Pod objects they are assigned to. It enforces that a kubelet with a specific node identity can only label, taint, or update its own Node object and can only create/modify Pods that are bound to that node. This prevents a compromised or misconfigured kubelet from tampering with other nodes or pods in the cluster.

Answer

AlwaysPullImages

Answer

PodSecurity

Answer

ServiceAccount

Question 15

Which of the following commands shows all loaded AppArmor profiles?

Accepted Answer

aa-status. The `aa-status` command displays the current status of AppArmor, including all loaded profiles, their enforcement mode (enforce/complain), and which processes are confined by them. This is the standard tool for listing active AppArmor profiles on a system.

Answer

apparmor_parser

Answer

aa-disable

Answer

aa-enforce