CKS Practice Exam 2 — 20 Questions

Question 1

A security best practice is to avoid storing sensitive data in environment variables. Instead, secrets should be mounted as volumes. Which of the following YAML snippets correctly mounts a Kubernetes Secret named 'db-secret' as a volume at /etc/secrets?

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

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets. It uses the `secret` volume type with the `secretName` field to reference the 'db-secret' Secret, and mounts it at /etc/secrets via a volumeMount. This adheres to the best practice of mounting secrets as volumes rather than injecting them as environment variables, which can be exposed in process listings or logs.

Answer

volumes:
- name: secret-volume
  secret:
    name: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets

Answer

volumes:
- name: secret-volume
  configMap:
    name: db-secret
containers:
- name: app
  volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets

Answer

containers:
- name: app
  env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

Question 2

Which kube-apiserver flag enables encryption at rest for secrets?

Accepted Answer

--encryption-provider-config. The `--encryption-provider-config` flag is the correct answer because it is the kube-apiserver flag that specifies the path to a configuration file containing the encryption providers (like `aescbc`, `secretbox`, or `aesgcm`) and the associated keys for encrypting Kubernetes secrets at rest. This flag enables the encryption at rest feature for secrets and other resources, as defined in the encryption configuration file.

Answer

--encryption-key-file

Answer

--secret-encryption

Answer

--enable-encryption

Question 3

An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?

Accepted Answer

SYS_ADMIN, SYS_MODULE, SYS_PTRACE. SYS_ADMIN, SYS_MODULE, and SYS_PTRACE are the most dangerous capabilities that enable container escape. SYS_ADMIN grants broad administrative privileges (e.g., mounting filesystems, accessing /proc/1/environ), SYS_MODULE allows loading kernel modules, and SYS_PTRACE permits tracing processes outside the container. Dropping these three capabilities is a key mitigation against kernel-level escapes.

Answer

CHOWN, DAC_OVERRIDE, FOWNER

Answer

KILL, SETPCAP, SYS_CHROOT

Answer

NET_RAW, NET_ADMIN, NET_BIND_SERVICE

Question 4

Which etcd security measure should be implemented to ensure only authorized clients can access the etcd cluster?

Accepted Answer

Enable TLS client-to-server authentication. Enabling TLS client-to-server authentication (mutual TLS) ensures that only clients presenting a valid certificate signed by a trusted Certificate Authority (CA) can communicate with the etcd cluster. This cryptographically verifies the client's identity, preventing unauthorized access and man-in-the-middle attacks. Without client certificate validation, any client with network access could potentially interact with etcd, compromising the Kubernetes control plane.

Answer

Enable anonymous authentication on etcd

Answer

Configure etcd to listen on localhost only

Answer

Use etcd RBAC with role-based access control

Question 5

An administrator wants to ensure that a Deployment uses a specific image digest (SHA256) instead of a tag. Which field in the Deployment YAML should be modified?

Accepted Answer

spec.template.spec.containers[].image. The `image` field under `spec.template.spec.containers[]` is where you specify the container image, and to enforce immutable deployment, you replace the tag with the SHA256 digest (e.g., `nginx@sha256:abc123...`). This ensures the exact image content is used, preventing tag mutation or accidental updates.

Answer

spec.replicas

Answer

spec.template.spec.containers[].imagePullPolicy

Answer

spec.template.metadata.annotations

Question 6

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Accepted Answer

They are compatible with the OCI runtime specification. Both gVisor and Kata Containers implement the OCI (Open Container Initiative) runtime specification, which allows them to be used as drop-in replacements for runc. This compatibility ensures that container images and tools like containerd can interface with these sandboxed runtimes without modification, as they expose the same runtime lifecycle commands (create, start, delete).

Answer

They improve container performance over native runc

Answer

They use the host kernel directly for all system calls

Question 7

Which of the following is NOT a recommended method to reduce the attack surface on Kubernetes nodes?

Accepted Answer

Running containers with privileged: true. Setting `privileged: true` in a container's security context grants it elevated capabilities equivalent to running as root on the host, including access to all kernel namespaces and devices. This directly increases the attack surface by allowing the container to perform host-level operations, such as loading kernel modules or modifying network settings, which violates the principle of least privilege. The CKS exam emphasizes that privileged containers should be avoided unless absolutely necessary, and they are never a recommended method for reducing the attack surface.

Answer

Using read-only root filesystems

Answer

Running containers as non-root

Answer

Disabling unnecessary system services on nodes

Question 8

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Accepted Answer

Mount Kubernetes Secrets as volumes into the pod.. Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Answer

Use environment variables from the pod spec referencing Secret keys.

Answer

Pass secrets as command-line arguments to the container.

Answer

Store secrets in ConfigMaps with base64 encoded data.

Question 9

Which of the following is a recommended setting from the CIS Kubernetes Benchmark for the kubelet?

Accepted Answer

--anonymous-auth=false. The CIS Kubernetes Benchmark recommends disabling anonymous authentication on the kubelet to ensure that all requests are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, reducing the attack surface and preventing unauthorized access to the kubelet API.

Answer

--authorization-mode=AlwaysAllow

Answer

--anonymous-auth=true

Answer

--read-only-port=10255

Question 10

You need to run a container with a sandboxed runtime using gVisor (runsc). Which Kubernetes resource must be created first to enable this?

Accepted Answer

A RuntimeClass resource with handler: runsc. A RuntimeClass resource is required to define a container runtime configuration that uses gVisor (runsc). When you create a RuntimeClass with handler: runsc, you can then reference it in a Pod spec via the runtimeClassName field, which instructs the kubelet to use the runsc runtime instead of the default runc. This is the foundational step to enable sandboxed runtime isolation for containers.

Answer

A PodSecurityPolicy that allows the runsc runtime

Answer

A ValidatingWebhookConfiguration to validate the runtime

Answer

A priorityClass with a high priority

Question 11

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?

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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