CKS Practice Questions 1 — 50 Questions

Question 1

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 2

You are using `crictl` to debug a container that is not responding. Which command should you use to get the list of running containers?

Accepted Answer

crictl ps. `crictl ps` is the correct command because it lists running containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O). This is analogous to `docker ps` but for the Kubernetes container runtime interface, allowing you to see container IDs, names, and statuses for debugging.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 3

You need to enable audit logging for the Kubernetes API server to capture all requests at the RequestResponse level. Which flag should you add to the kube-apiserver configuration?

Accepted Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml. Audit-policy-file. This flag specifies the path to the audit policy file, which defines the rules for auditing. The other options are incorrect: --audit-log-path only sets the log file location, not the audit level; --audit-webhook-config-file is for sending audit events to a webhook; and --authorization-mode controls RBAC, not audit logging. To capture requests at RequestResponse level, the audit policy must specify that level, and the --audit-policy-file flag is required.

Answer

--audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml

Answer

--audit-log-path=/var/log/audit.log

Answer

--authorization-mode=RBAC

Question 4

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

Accepted Answer

Validating webhooks should run before mutating webhooks. In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added. The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue. Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Answer

Use a validating webhook instead of ImagePolicyWebhook

Answer

The mutating webhook should be configured to skip pods with certain images

Answer

The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

Question 5

Match each container security context setting to its effect.

Accepted Answer

runAsNonRoot: Prevents the container from running as root. Correct matches: runAsNonRoot forces non-root execution; runAsUser sets a specific UID. Common confusion is swapping these effects. Other settings like privileged and readOnlyRootFilesystem also enforce least privilege.

Answer

runAsNonRoot: Specifies the user ID (UID) to run the container

Answer

runAsUser: Prevents the container from running as root

Question 6

A developer reports that a pod cannot reach an external database at 192.168.1.100:3306. The pod's namespace is 'app'. You need to create a NetworkPolicy that allows egress to that IP only. Which policy is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
    ports:
    - port: 3306
      protocol: TCP
  policyTypes:
  - Egress. The correct NetworkPolicy must allow egress traffic from pods in the 'app' namespace to the specific IP 192.168.1.100 on port 3306. Option D meets this requirement by using 'podSelector: {}' to apply to all pods, specifying an egress rule to the ipBlock with the correct CIDR and port 3306, and setting 'policyTypes: [Egress]'. Option A is missing the port specification, so it would allow egress to the IP on any port, which is too permissive. Option B uses 'matchLabels: app: myapp', restricting the policy to pods with that label, and also lacks the port. Option C defines an ingress rule instead of egress, which does not address the egress requirement.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Egress

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: myapp
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Egress

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress
  namespace: app
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.100/32
  policyTypes:
  - Ingress

Question 7

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

Accepted Answer

The Rego rule does not set 'violation' to true when the label is missing. Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly. In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

Answer

The Constraint is not bound to any namespaces

Answer

The Deployment has the label set but with a different value

Answer

Gatekeeper is not installed in the cluster

Question 8

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 9

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Accepted Answer

Use Kyverno policy engine. Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Answer

Run kube-bench on the cluster

Answer

Manual review of all pod specs

Question 10

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Answer

--read-only-port=0

Answer

--anonymous-auth=false

Answer

--kubelet-extra-args

Question 11

You are asked to generate an SBOM for a container image and attach it as an attestation using cosign. Which two commands would you run in sequence?

Accepted Answer

syft myimage:latest -o spdx > sbom.spdx && cosign attest --type spdx --predicate sbom.spdx myimage:latest. It first uses Syft to generate an SPDX-format SBOM from the container image, then uses cosign attest to attach that SBOM as an in-toto attestation to the image. This sequence satisfies the requirement to generate an SBOM and attach it as an attestation using cosign.

Answer

trivy image --format spdx myimage:latest > sbom.spdx && cosign verify --key cosign.pub myimage:latest

Answer

cosign sign --key cosign.key myimage:latest && syft myimage:latest -o spdx

Answer

crane ls myimage:latest && cosign attest --type spdx --predicate sbom.spdx myimage:latest

Question 12

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor has two operational modes: 'enforce' and 'complain'. In 'enforce' mode, AppArmor actively enforces the security policy, blocking actions that violate the profile and logging the denial. In 'complain' mode, AppArmor logs policy violations but does not block them, allowing administrators to test profiles before enforcing them.

Answer

audit

Answer

allow

Answer

unconfined

Question 13

An auditor requires that all audit logs from the Kubernetes API server be stored for 90 days and be tamper-proof. Which TWO measures should be implemented?

Accepted Answer

Configure the audit log backend to write to an immutable object store like S3 with Object Lock. Storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Answer

Enable the AuditDynamicConfiguration feature gate

Answer

Deploy Fluentd to forward logs to a central Elasticsearch cluster

Answer

Set --audit-log-maxbackup=10 and --audit-log-maxsize=100

Question 14

A developer wants to ensure that all containers in a pod run with a read-only root filesystem except for a specific volume mounted for writing logs. Which container-level security context field should be set to true?

Accepted Answer

readOnlyRootFilesystem. Setting `readOnlyRootFilesystem: true` in the container-level security context forces the container's root filesystem to be read-only, preventing any writes to the root filesystem. This is exactly what the developer needs to enforce immutability for the root filesystem while allowing writes only to a specific volume (e.g., for logs) mounted with write access. The field is a boolean in the `securityContext` of a container specification in Kubernetes.

Answer

allowPrivilegeEscalation

Answer

privileged

Answer

runAsNonRoot

Question 15

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

Accepted Answer

Store the API key in a Kubernetes Secret and mount it as a volume inside the container. Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Answer

Store the API key in a ConfigMap and expose it as an environment variable

Answer

Hardcode the API key in the container image

Answer

Store the API key in a Kubernetes Secret and expose it as an environment variable

Question 16

Match each Kubernetes security component to its description.

Accepted Answer

RBAC: Role-based access control for managing permissions.. RBAC controls permissions, Pod Security Admission enforces pod security, Network Policies manage traffic, and ServiceAccounts provide identity. Distractors confuse these functions.

Answer

RBAC: Encrypts data at rest.

Answer

ServiceAccount: Manages network rules.

Question 17

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

Accepted Answer

Run a vulnerability scan on the container image. Running a vulnerability scan on the container image (Option A) is the most effective step because it directly checks the image layers and installed packages against known Common Vulnerabilities and Exposures (CVEs) databases, such as the National Vulnerability Database (NVD). This identifies security flaws in base images and dependencies before deployment, which is a core requirement of supply chain security in Kubernetes.

Answer

Check the image size

Answer

Run unit tests on the application code

Answer

Lint the Dockerfile

Question 18

What is the purpose of an SBOM (Software Bill of Materials) in the context of supply chain security?

Accepted Answer

To provide a list of all software components and dependencies in an artifact. An SBOM lists all software components and dependencies in an artifact, enabling vulnerability tracking and compliance. Option C is correct.

Answer

To sign container images

Answer

To scan images for vulnerabilities

Answer

To enforce runtime security policies

Question 19

To ensure a container's filesystem is read-only, which field should be set to 'true' in the container spec?

Accepted Answer

securityContext.readOnlyRootFilesystem. The securityContext field readOnlyRootFilesystem controls whether the container's root filesystem is read-only. The other options are either non-existent or have different effects.

Answer

securityContext.runAsNonRoot

Answer

container.fsGroup

Answer

podSpec.containers.readonly

Question 20

An administrator wants to set an immutable root filesystem for a container in a Pod. Which securityContext field should be set to true?

Accepted Answer

readOnlyRootFilesystem. The 'readOnlyRootFilesystem' field, when true, mounts the container's root filesystem as read-only, preventing writes.

Answer

allowPrivilegeEscalation

Answer

runAsNonRoot

Answer

privileged