CKS Practice Test 4 — 10 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