CKS Practice Questions

Question 1

A DevOps team uses a CI/CD pipeline to build container images and push them to a private registry. To minimize the risk of supply chain attacks, which of the following is the most effective security control to implement?

Accepted Answer

Sign all container images using a private key and verify the signature before deployment.. Signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Answer

Scan all images for vulnerabilities using Trivy before pushing to the registry.

Answer

Restrict access to the registry using Kubernetes RBAC and service accounts.

Answer

Implement network policies to restrict traffic to the registry endpoint.

Question 2

Which of the following YAML snippets correctly configures a ServiceAccount with automountServiceAccountToken set to false?

Accepted Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
automountServiceAccountToken: false. It uses the correct field name `automountServiceAccountToken` at the top level of the ServiceAccount spec, which is the proper way to disable automatic mounting of the service account token in pods that use this ServiceAccount. This setting prevents the Kubernetes API token from being automatically injected into pods, enhancing security by reducing the attack surface for token theft.

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
token:
  automount: false

Answer

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-sa
  automountServiceAccountToken: false

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
  automountServiceAccountToken: false

Question 3

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

Accepted Answer

Enable the PodSecurityPolicy admission controller, create a PodSecurityPolicy resource, grant RBAC access to the policy, and verify enforcement by testing a pod.. PSPs require enabling the admission controller, creating the policy, granting access via RBAC, and binding to subjects. Testing confirms enforcement.

Answer

Create a PodSecurityPolicy resource, enable the PodSecurityPolicy admission controller, grant RBAC access, and verify enforcement.

Answer

Grant RBAC access to the PodSecurityPolicy, enable the admission controller, create the policy, and verify enforcement.

Answer

Enable the PodSecurityPolicy admission controller, create a PodSecurityPolicy resource, verify enforcement, and grant RBAC access.

Question 4

Which tool is used to generate a Software Bill of Materials (SBOM) for a container image?

Accepted Answer

Syft. Syft is an open-source CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses static analysis to extract package metadata (e.g., dpkg, RPM, APK, Python, Java) and outputs the SBOM in formats like CycloneDX or SPDX, which are the industry standards for supply chain transparency. This makes Syft the correct tool for generating an SBOM from a container image.

Answer

Kubesec

Answer

Checkov

Answer

Trivy

Question 5

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What is the security concern?

Accepted Answer

It grants too broad permissions to the service account. The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.

Answer

The binding should be a RoleBinding instead of ClusterRoleBinding

Answer

The service account name must be changed

Answer

The binding is fine as long as the service account is used in the default namespace

Question 6

A security policy requires that all container images use SHA-based digests instead of tags. Which approach ensures this in a Deployment YAML?

Accepted Answer

Use the image field with a digest, e.g., 'image: nginx@sha256:abc123'. Kubernetes supports using a SHA-based digest in the `image` field, which ensures the exact image content is pulled regardless of tag changes. By specifying the image as `nginx@sha256:abc123`, the container runtime fetches the image by its immutable digest, guaranteeing supply chain integrity and compliance with the security policy.

Answer

Use the 'image' field with a tag and also set 'digest' field

Answer

Set imagePullPolicy: Always and use tags

Answer

Set imagePullPolicy: IfNotPresent and use tags

Question 7

A pod in namespace 'ns1' has automountServiceAccountToken: false. However, the container still has a mounted service account token at /var/run/secrets/kubernetes.io/serviceaccount. What is the most likely cause?

Accepted Answer

The automountServiceAccountToken field is set in the container spec instead of the pod spec. The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies. This is why the token still appears mounted despite the intention to disable it.

Answer

The kubelet is configured to always mount tokens

Answer

The namespace has a default automountServiceAccountToken: true

Answer

The pod is using a custom service account with automountServiceAccountToken: true

Question 8

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

Accepted Answer

kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml. The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Answer

kubectl cordon <node-of-compromised-pod>

Answer

kubectl delete pod compromised-pod && kubectl describe pod compromised-pod

Answer

kubectl exec compromised-pod -- killall miner-process

Question 9

Which annotation is used to apply an AppArmor profile to a pod in Kubernetes?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The annotation `container.apparmor.security.beta.kubernetes.io/` is the standard annotation used to apply an AppArmor profile to a specific container within a pod. The `` placeholder must be replaced with the actual container name, and the annotation value specifies the profile (e.g., `localhost/profile-name` or `runtime/default`). This annotation is in the `security.beta.kubernetes.io` API group, reflecting its beta status in Kubernetes.

Answer

seccomp.security.alpha.kubernetes.io/pod

Answer

apparmor.security.beta.kubernetes.io/profile

Answer

container.apparmor.kubernetes.io/<container_name>

Question 10

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

Accepted Answer

The profile is in complain mode, not enforce mode. AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Answer

The pod must run as privileged to use AppArmor

Answer

The annotation is missing the 'localhost/' prefix

Answer

The profile is not loaded on the node

Question 11

An admin runs 'kubectl auth reconcile -f rbac.yaml' and gets an error that the user does not have permission to create ClusterRoleBindings. What is the most likely cause?

Accepted Answer

The user's kubeconfig context does not have RBAC permissions to create ClusterRoleBindings.. The error indicates that the user's current kubeconfig context lacks RBAC permissions to create ClusterRoleBindings. The `kubectl auth reconcile` command attempts to apply the RBAC resources defined in the YAML file, and if the user's credentials (typically from a certificate or token) do not include the `create` verb on `clusterrolebindings` in the RBAC authorization layer, the API server will reject the request with a 403 Forbidden error. This is a direct permission issue, not a connectivity or syntax problem.

Answer

The ClusterRoleBinding already exists.

Answer

The YAML file has a syntax error.

Answer

The Kubernetes API server is not reachable.

Question 12

Which of the following is correct about dropping the 'NET_RAW' capability?

Accepted Answer

It prevents the container from creating raw sockets, which can be used for packet crafting attacks. The `NET_RAW` capability controls access to raw and packet sockets (AF_PACKET, SOCK_RAW). Dropping it prevents the container from creating raw sockets, which are often used for crafting custom packets, performing ARP spoofing, or launching other network-layer attacks. This is a key hardening measure to reduce the container's ability to manipulate network traffic at the low level.

Answer

It prevents the container from binding to a privileged port (<1024)

Answer

It prevents the container from using the 'ping' command

Answer

It prevents the container from making any network connections

Question 13

You need to use gVisor as a container runtime for a set of workloads in the cluster. Which Kubernetes resource must be created to reference the runtime class?

Accepted Answer

Create a RuntimeClass resource with handler: runsc. In Kubernetes, a RuntimeClass resource is used to select a container runtime configuration, such as gVisor. The RuntimeClass must specify the handler field set to 'runsc', which is the gVisor runtime binary. This resource is then referenced by pods via the `runtimeClassName` field to enforce sandboxed isolation.

Answer

Set the kubelet runtime flag --runtime-class=gvisor

Answer

Install a CRD for gVisor

Answer

Create a Pod with spec.runtimeClassName set to "gvisor"

Question 14

A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?

Accepted Answer

Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'. The 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Answer

Add a PodSecurityPolicy that sets seccomp to RuntimeDefault

Answer

Use a cronjob to audit and modify pods that do not have seccomp set

Answer

Add a seccomp profile to the kubelet configuration

Question 15

An administrator wants to ensure that a service account used by a deployment cannot automatically mount its token. Which field should be set to `false` in the Pod spec?

Accepted Answer

automountServiceAccountToken. The `automountServiceAccountToken` field in the Pod spec controls whether the service account token is automatically mounted into the container. Setting this field to `false` prevents the automatic mounting of the token, which is a security best practice to reduce the attack surface for compromised pods. This field can be set at the Pod level or overridden at the ServiceAccount level.

Answer

mountServiceAccountToken

Answer

disableTokenMount

Answer

automountToken

Certified Kubernetes Security Specialist CKS practice test

Three ways to study

Study CKS by domain

Study CKS by topic

Minimize Microservice Vulnerabilities practice questions

Supply Chain Security practice questions

Monitoring, Logging and Runtime Security practice questions

System Hardening practice questions

Cluster Setup practice questions

Cluster Hardening practice questions

CKS fundamentals practice questions

CKS scenario practice questions

CKS troubleshooting practice questions

Top CKS questions

Certified Kubernetes Security Specialist CKS practice questions