CKS Practice Test 4 — 25 Questions

Question 1

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

Accepted Answer

PeerAuthentication with mTLS mode set to STRICT. PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls configuration

Answer

ServiceEntry with mTLS enabled

Question 2

A pod is in a CrashLoopBackOff state. You run 'kubectl logs pod-name' and see: 'Error: failed to start container: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the /app executable. The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Answer

The pod is out of memory

Answer

The container's working directory is incorrect

Answer

The pod has a liveness probe that is failing

Question 3

Which of the following is a best practice when writing a Dockerfile for a containerized application?

Accepted Answer

Use a minimal base image such as distroless or alpine. Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.

Answer

Run the application as the root user for file permissions

Answer

Hardcode credentials in the Dockerfile for convenience

Answer

Use the latest tag for the base image to get the newest features

Question 4

An administrator runs kube-bench on a node and sees a warning about the kubelet anonymous authentication being enabled. Which kubelet flag should be set to disable anonymous access?

Accepted Answer

--anonymous-auth=false. The kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Answer

--anonymous-auth=true

Answer

--enable-anonymous=false

Answer

--disable-anonymous=true

Question 5

Which of the following is a best practice for storing sensitive information like database passwords in Kubernetes?

Accepted Answer

Mount secrets as volumes in the pod. Mounting secrets as volumes ensures that sensitive data is stored in the in-memory tmpfs filesystem, which is never written to disk and is automatically removed when the pod is deleted. This approach also allows for automatic updates of secret values when the Secret object is modified, without requiring a pod restart, and provides better access control through filesystem permissions.

Answer

Use environment variables in the pod spec to pass secrets

Answer

Embed secrets as literals in the pod YAML file

Answer

Store them in ConfigMaps

Question 6

Which TWO of the following are valid AppArmor profile modes?

Accepted Answer

Complain. AppArmor has two primary operational modes: 'Complain' (also known as 'learning' mode) and 'Enforce'. In Complain mode, policy violations are logged but not blocked, allowing administrators to test profiles. In Enforce mode, violations are both logged and blocked, actively enforcing the security policy.

Answer

Audit

Answer

Disable

Answer

Permissive

Question 7

An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.

Answer

--disable-anonymous

Answer

--authorization-mode=RBAC

Answer

--enable-admission-plugins=DenyAnonymous

Question 8

An administrator wants to enable audit logging for the Kubernetes API server. Which of the following is required?

Accepted Answer

Set --audit-log-path and --audit-policy-file flags on the kube-apiserver. Audit logging in Kubernetes is configured directly on the kube-apiserver component. The `--audit-log-path` flag specifies the file path where audit logs are written, and the `--audit-policy-file` flag points to a YAML file that defines which events (e.g., requests, responses, metadata) should be logged and at what level (e.g., Metadata, Request, RequestResponse). These flags are required to enable and control audit logging; no feature gate is needed because audit logging is built-in since Kubernetes 1.8.

Answer

Enable the AuditLogging feature gate

Answer

Create a ClusterRoleBinding with audit permissions

Answer

Set --audit-log-path flag on the kubelet

Question 9

An administrator wants to restrict which nodes a pod can be scheduled on using the NodeRestriction admission plugin. Which flag must be set on the kube-apiserver to enable this plugin?

Accepted Answer

--enable-admission-plugins=NodeRestriction. The NodeRestriction admission plugin limits the labels and taints that a kubelet running on a node can modify on its own Node object. To enable it, the `--enable-admission-plugins=NodeRestriction` flag must be set on the kube-apiserver, as admission plugins are enabled via this flag. This plugin works in conjunction with the Node authorizer and the NodeRestriction admission controller to enforce node-level restrictions.

Answer

--admission-control=NodeRestriction

Answer

--enable-admission-plugins=PodNodeSelector

Answer

--authorization-mode=Node

Question 10

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

Accepted Answer

The container runs as user 1001. When `runAsNonRoot: true` is set, Kubernetes enforces that the container cannot run as root (UID 0). However, the pod also specifies `runAsUser: 1001`, which tells Kubernetes to run the container as UID 1001. Since UID 1001 is non-root, the `runAsNonRoot` constraint is satisfied. The container image's expectation to run as root is irrelevant because Kubernetes overrides the user with the specified `runAsUser`. Therefore, the container will start and run as user 1001.

Answer

The container runs as root because runAsUser overrides runAsNonRoot

Answer

The container fails to start because it cannot run as root

Answer

The pod runs, but the securityContext is ignored

Question 11

You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

Accepted Answer

deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }. Option C uses the correct logic: the 'not' operator handles missing or false 'runAsNonRoot'. It also returns the expected object format {"msg": "..."}, which Gatekeeper requires. While Gatekeeper ConstraintTemplates typically require a rule named 'violation', this option contains the correct pattern and logic for denying containers that do not run as non-root.

Answer

allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }

Answer

deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }

Answer

deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }

Question 12

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes?

Accepted Answer

Minimize host access from containers (e.g., disable hostPID, hostNetwork). Disabling hostPID and hostNetwork prevents containers from accessing the host's process namespace and network stack, which would otherwise allow privilege escalation or network sniffing. This aligns with the principle of least privilege and reduces the node's attack surface by isolating container workloads from the host OS.

Answer

Expose the host network to containers for better performance

Answer

Run containers as root to simplify permissions

Question 13

A Kyverno policy is written to require all images to use SHA256 digests instead of tags. The policy uses a 'validate' rule with 'pattern' on 'spec.containers[*].image'. Which pattern would match an image reference like 'registry.example.com/myapp@sha256:abc123...'?

Accepted Answer

"*@sha256:*". Option C ('*@sha256:*') correctly matches image references using SHA256 digest. It ensures the digest algorithm is exactly 'sha256' followed by a colon and digest. Option A ('*@sha256*') is too permissive as it matches any image reference containing 'sha256' as a substring, potentially allowing other algorithms like 'sha256-extra'. Option B ('*@*') matches any digest algorithm, not specifically SHA256. Option D ('*:*') matches tags, not digests. Therefore, only C meets the requirement.

Answer

*@sha256*

Answer

"*@*"

Answer

"*:*"

Question 14

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

Accepted Answer

The webhook service is not running or is unreachable. The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.

Answer

The webhook is not matching the namespace labels

Answer

The webhook is configured with failurePolicy: Fail

Answer

The pod is being created by a controller like a Deployment

Question 15

You need to set up a ValidatingWebhookConfiguration to deny pods that run as root. The webhook server is deployed in the 'webhook' namespace with service 'webhook-svc' on port 443. Which of the following is a correct snippet for the webhook configuration?

Accepted Answer

clientConfig:
  service:
    name: webhook-svc
    namespace: webhook
    path: /validate
    port: 443. It properly defines a service reference with the required fields: name, namespace, and path. The port field is explicitly set to 443, matching the webhook server's listening port. In Kubernetes, when using a service reference and the webhook server's certificate is signed by the cluster's CA (which is typical for in-cluster services), the caBundle field may be omitted as the API server can use its own CA bundle to verify the connection. Thus, the configuration in A is complete and valid for this scenario.

Answer

clientConfig:
  url: https://10.96.0.1:443/validate

Answer

clientConfig:
  url: https://webhook-svc.webhook.svc:443/validate

Answer

clientConfig:
  service:
    name: webhook-svc
    namespace: webhook
    path: /validate
  caBundle: <base64>

Question 16

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

Accepted Answer

Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities. It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Answer

Set securityContext.capabilities.drop: ['ALL'] with no add

Answer

Leave capabilities unset to use the default set

Answer

Add only the necessary capabilities without dropping

Question 17

You are implementing a policy to ensure all containers in a namespace run as non-root. Which of the following is the most appropriate approach to enforce this at the cluster level?

Accepted Answer

Use OPA/Gatekeeper with a ConstraintTemplate that checks runAsNonRoot is set to true. OPA/Gatekeeper allows you to enforce custom policies at the cluster level via ConstraintTemplates and Constraints. By creating a ConstraintTemplate that checks `runAsNonRoot: true` in the Pod securityContext, you can ensure all Pods in a namespace (or cluster-wide) run as non-root, without modifying individual Pod specs. This approach is native to Kubernetes admission control and provides a flexible, cluster-wide enforcement mechanism.

Answer

Create a PodSecurityPolicy that requires runAsNonRoot

Answer

Set runAsNonRoot in the securityContext of each Pod spec manually

Answer

Configure a ValidatingAdmissionPolicy with a CEL rule requiring runAsNonRoot

Question 18

Which admission plugin should be enabled on the kube-apiserver to restrict kubelet permissions and prevent nodes from modifying their own Node objects?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the kubelet's permissions to only modify labels, annotations, and status on its own Node object, preventing a compromised or misconfigured node from altering other Node objects or escalating privileges. This is a critical hardening measure for cluster setup, as it enforces the principle of least privilege on kubelet API access.

Answer

ServiceAccount

Answer

AlwaysPullImages

Answer

PodSecurityPolicy

Question 19

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 20

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