CKS Practice Test 2 — 30 Questions

Question 1

An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.. It implements a complete chain of custody for container images. In-toto generates signed attestations that record every step of the CI/CD pipeline (e.g., source code checkout, build, test), and an admission webhook like Kyverno verifies these attestations before allowing a pod to run. This ensures that only images that passed the exact, attested pipeline are deployed, providing the strongest guarantee against unauthorized or tampered images.

Answer

Implement network policies to restrict egress from pods to the registry.

Answer

Grant registry write access only to the CI system's service account.

Answer

Use a static analysis tool to check the Dockerfile before building.

Answer

Use a unique registry path and restrict access via firewall rules.

Question 2

You run 'kube-bench' on a cluster node and get a failure for the test 'Ensure that the --anonymous-auth argument is set to false' (ID: 1.2.1). Which file do you need to modify to fix this issue?

Accepted Answer

/etc/kubernetes/manifests/kube-apiserver.yaml. The kube-bench test ID 1.2.1 checks the kube-apiserver configuration for the `--anonymous-auth` flag. The API server is a static pod managed by the kubelet, and its configuration is defined in the manifest file `/etc/kubernetes/manifests/kube-apiserver.yaml`. To fix the failure, you must edit this file to set `--anonymous-auth=false`.

Answer

/etc/kubernetes/kubelet.conf

Answer

/etc/kubernetes/pki/

Answer

/var/lib/kubelet/config.yaml

Question 3

An audit policy is configured with level: Request. Which operations are recorded in the audit log?

Accepted Answer

Request metadata and the request body. When an audit policy is configured with `level: Request`, the API server logs the request metadata and the request body for all operations. This is defined in the Kubernetes audit policy specification, where the `Request` level captures the entire request object, including metadata and the body, but does not include the response. This level is useful for debugging and security analysis without the overhead of logging response data.

Answer

Nothing, only the fact that a request occurred

Answer

Request and response metadata and bodies

Answer

Only metadata about the request

Question 4

A pod with the following annotation is created: 'container.apparmor.security.beta.kubernetes.io/webserver: localhost/k8s-apparmor-profile'. However, the pod remains in 'Pending' state and the node logs show 'AppArmor not available'. What is the most likely cause?

Accepted Answer

AppArmor is not loaded or enabled on the node kernel. The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

Answer

The annotation should be on the pod's securityContext, not as an annotation

Answer

The AppArmor profile name is misspelled

Answer

The pod is using a privileged security context

Question 5

What is the default authorization mode for a new Kubernetes cluster?

Accepted Answer

RBAC. RBAC (Role-Based Access Control) is the default authorization mode for new Kubernetes clusters since version 1.8. When you initialize a cluster with kubeadm, the API server is automatically configured with the `--authorization-mode=RBAC` flag, enabling fine-grained access control based on roles and bindings.

Answer

ABAC

Answer

Node

Answer

AlwaysDeny

Question 6

You run kube-bench on a node and it reports a failure for 'Ensure that the --anonymous-auth argument is set to false' for the kubelet service. Which file must you modify to fix this?

Accepted Answer

/var/lib/kubelet/config.yaml. Kube-bench checks the kubelet configuration for the `--anonymous-auth` flag, which is set in the kubelet's configuration file. By default, the kubelet reads its configuration from `/var/lib/kubelet/config.yaml` (or a path specified by `--config` in the kubelet service). Setting `anonymous-auth: false` in this file disables anonymous requests to the kubelet API, enforcing authentication.

Answer

/etc/kubernetes/manifests/kube-apiserver.yaml

Answer

/etc/kubernetes/pki/ca.crt

Answer

/etc/kubernetes/kubelet.conf

Question 7

You need to run kube-bench on a control plane node. Which command should you use?

Accepted Answer

kube-bench run --targets=master. `kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

Answer

kube-bench run --targets=controlplane

Answer

kube-bench run --targets=node

Answer

kube-bench run --targets=etcd

Question 8

An administrator runs 'aa-status' on a node and sees a profile in 'complain' mode. What does this indicate?

Accepted Answer

The profile logs violations but does not block them.. AppArmor profiles in 'complain' mode log policy violations to the system log (e.g., /var/log/syslog or audit.log) but do not enforce them, meaning the actions are allowed while being recorded. This is distinct from 'enforce' mode, where violations are blocked. The 'aa-status' command shows the current mode of loaded profiles.

Answer

The profile is disabled and has no effect.

Answer

The profile is enforcing restrictions and blocking violations.

Answer

The profile is not loaded.

Question 9

A pod is scheduled on a node that has AppArmor enabled, and the pod has the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write'. The profile 'deny-write' is loaded. However, the nginx container is able to write to the filesystem. What is the most likely issue?

Accepted Answer

The profile was loaded in complain mode using apparmor_parser with the -C flag. The most likely issue is that the AppArmor profile 'deny-write' was loaded in complain mode using the `apparmor_parser` with the `-C` flag. In complain mode, AppArmor logs policy violations but does not enforce them, allowing the container to write to the filesystem despite the profile being applied. The annotation is correctly formatted, and the profile is loaded, so enforcement depends on the mode.

Answer

The container is privileged

Answer

The pod's securityContext sets allowPrivilegeEscalation to true

Answer

The annotation is incorrectly formatted

Question 10

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 11

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Answer

Docker

Answer

containerd

Answer

runc

Question 12

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Answer

PodSecurityPolicy (deprecated)

Answer

ResourceQuota

Answer

ValidatingAdmissionPolicy

Question 13

Which TWO of the following are valid methods to securely manage secrets in Kubernetes?

Accepted Answer

Use Kubernetes Secrets with encryption at rest enabled. Kubernetes Secrets can be encrypted at rest using a KMS provider (e.g., AWS KMS, Azure Key Vault, or GCP Cloud KMS) configured via the EncryptionConfiguration resource. This ensures that Secret data is encrypted in etcd, protecting it from unauthorized access if the etcd database is compromised. Encryption at rest is a critical security control for secrets in Kubernetes.

Answer

Store secrets in ConfigMaps and use them in pods

Answer

Commit secrets to a private Git repository

Answer

Store secrets directly in the application code

Question 14

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Accepted Answer

Set runAsNonRoot: true in the pod securityContext. Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.

Answer

Set the container image to use a root user

Answer

Use a PodSecurityPolicy (PSP)

Answer

Set runAsUser: 0 in the container securityContext

Question 15

Which TWO of the following are valid methods to verify the integrity of a container image? (Select 2)

Accepted Answer

Compare the image SHA digest with a known good digest. Container images are identified by a content-addressable digest (SHA256 hash) that uniquely represents the image manifest. Verifying that the SHA digest of a pulled image matches a known good digest from a trusted source ensures the image has not been tampered with or altered in transit, as any change to the image layers or configuration would result in a different digest.

Answer

Use trivy image to check for vulnerabilities

Answer

Use docker history to view layers

Answer

Use kubectl describe pod to check image details

Question 16

Which two of the following are correct ways to enforce least privilege for service accounts? (Choose two.)

Accepted Answer

Set automountServiceAccountToken: false in Pod spec for pods that do not need API access. Setting `automountServiceAccountToken: false` in the Pod spec prevents the automatic mounting of the service account token into the container. This enforces least privilege by ensuring that pods which do not require API access cannot inadvertently use the token to authenticate to the Kubernetes API server, reducing the attack surface.

Answer

Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

Answer

Use the default service account for all workloads

Answer

Grant cluster-admin ClusterRole to the service account for simplicity

Question 17

An admin runs 'kubectl run nginx --image=nginx' and the pod fails with 'ImagePullBackOff'. The cluster has an OPA/Gatekeeper constraint that only allows images from 'myregistry.io'. How can the admin quickly test the restriction?

Accepted Answer

Use an image from 'myregistry.io/nginx:latest'. The OPA/Gatekeeper constraint explicitly restricts allowed images to those from 'myregistry.io'. By specifying an image from that registry (e.g., 'myregistry.io/nginx:latest'), the admin can quickly verify that the constraint permits compliant images. This tests the policy's intended behavior without altering or bypassing the constraint.

Answer

Delete the OPA constraint

Answer

Add a label 'allowlist=true' to the pod

Answer

Use 'kubectl run nginx --image=nginx --validate=false'

Question 18

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Accepted Answer

Enforce that containers set runAsNonRoot: true.. Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Answer

Allow privileged containers for system-critical workloads.

Answer

Allow containers to use hostNetwork for easier service discovery.

Question 19

Which TWO resources can be used to implement RBAC in Kubernetes?

Accepted Answer

ClusterRole. A is correct because ClusterRole is a Kubernetes RBAC resource that defines a set of permissions (rules) that are not namespaced, allowing cluster-wide access. RBAC in Kubernetes uses Role and ClusterRole objects to specify allowed verbs (e.g., get, list, create) on resources (e.g., pods, secrets), and they are bound to subjects via RoleBinding or ClusterRoleBinding.

Answer

NetworkPolicy

Answer

PodSecurityPolicy

Answer

ServiceAccount

Question 20

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Accepted Answer

Enable the NodeRestriction admission controller. The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Answer

Set --anonymous-auth=true to allow all users

Answer

Enable audit logging to detect unauthorized attempts

Answer

Disable all authentication mechanisms and rely on network policies