CKS System Hardening Practice Test 4 — 15 Questions

Question 1

A pod is configured with a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. The pod manifest uses securityContext.seccompProfile with type: Localhost and localhostProfile: "custom-profile.json". The pod fails to start with an error 'seccomp profile not found'. What is the most likely cause?

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

Accepted Answer

The custom-profile.json file is not present on the node filesystem.. The error 'seccomp profile not found' indicates that the Kubernetes kubelet cannot locate the specified profile file on the node's filesystem. When using `type: Localhost`, the `localhostProfile` value is resolved relative to the kubelet's seccomp profile root directory (default `/var/lib/kubelet/seccomp`). If the file `custom-profile.json` does not exist at that path on the node, the pod will fail to start.

Answer

The securityContext.seccompProfile.defaultRuntimeProfile field must be set to 'custom-profile.json'.

Answer

The seccomp profile should be defined in the pod's annotations, not securityContext.

Answer

The localhostProfile field must be an absolute path.

Question 2

Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?

Accepted Answer

securityContext:
  capabilities:
    add:
    - NET_ADMIN. In Kubernetes, the correct field to add a Linux capability to a container is `capabilities.add` in the container's `securityContext`. Option B uses `add: - NET_ADMIN` at the container level, which is the proper syntax. Option D uses `cap_add`, which is Docker Compose syntax and invalid in Kubernetes. Option A uses `cap_add` with `ALL`, which adds all capabilities and is not specific. Option C places the `securityContext` at the pod spec level, but the pod-level `securityContext` does not support a `capabilities` field; capabilities must be set in each container's `securityContext`. Therefore, C is invalid, not just less precise.

Answer

securityContext:
  capabilities:
    cap_add:
    - ALL

Answer

securityContext:
  capabilities:
    cap_add:
    - NET_ADMIN
(but placed at pod spec level)

Answer

securityContext:
  capabilities:
    cap_add:
    - NET_ADMIN

Question 3

An administrator wants to prevent a container from accessing the host's network. Which pod security context field should be set to false?

Accepted Answer

hostNetwork. The `hostNetwork` field in the Pod Security Context, when set to `true`, allows the container to use the host's network namespace directly, bypassing the pod's own network stack. Setting it to `false` (the default) ensures the container uses an isolated network namespace, preventing direct access to host network interfaces, iptables rules, and network services. This is the correct field to disable to meet the requirement of preventing container access to the host's network.

Answer

hostIPC

Answer

privileged

Answer

hostPID

Question 4

A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?

Accepted Answer

capabilities.drop: ["ALL"] capabilities.add: ["NET_BIND_SERVICE"]. It drops all Linux capabilities using `capabilities.drop: ["ALL"]` and then explicitly adds only the necessary `NET_BIND_SERVICE` capability via `capabilities.add: ["NET_BIND_SERVICE"]`. This adheres to the principle of least privilege by starting from a clean slate and granting only the required capability. In Kubernetes security contexts, the correct keys are `capabilities.drop` and `capabilities.add` under the `securityContext` field. Options B and D partially meet the requirement but do not drop all capabilities; Option C adds all capabilities, violating the policy.

Answer

cap_drop: ["NET_RAW"]

Answer

cap_add: ["ALL"]

Answer

cap_add: ["NET_BIND_SERVICE"]

Question 5

Which of the following commands shows all loaded AppArmor profiles?

Accepted Answer

aa-status. The `aa-status` command displays the current status of AppArmor, including all loaded profiles, their enforcement mode (enforce/complain), and which processes are confined by them. This is the standard tool for listing active AppArmor profiles on a system.

Answer

apparmor_parser

Answer

aa-disable

Answer

aa-enforce

Question 6

A cluster administrator wants to enforce Pod Security Standards at the namespace level using the built-in PodSecurity admission controller. The namespace 'test' should reject any pod that violates the 'baseline' level. Which command applies this correctly?

Accepted Answer

kubectl label ns test pod-security.kubernetes.io/enforce=baseline. The PodSecurity admission controller uses the label `pod-security.kubernetes.io/enforce` to enforce the specified Pod Security Standard (e.g., `baseline`) at the namespace level. Pods that violate the enforced level are rejected by the admission controller. The `enforce` label triggers the admission webhook to block non-compliant pods, which matches the requirement to reject violations.

Answer

kubectl annotate ns test pod-security.kubernetes.io/enforce-version=baseline

Answer

kubectl label ns test pod-security.kubernetes.io/warn=baseline

Answer

kubectl label ns test pod-security.kubernetes.io/audit=baseline

Question 7

A custom seccomp profile is defined as follows:
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["mkdir", "chmod"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}
The profile is placed at /var/lib/kubelet/seccomp/deny-mkdir.json. Which pod securityContext configuration correctly applies this profile?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: "deny-mkdir.json". In Kubernetes, the `seccompProfile` field in the pod or container security context uses the `type: Localhost` (case-sensitive) and `localhostProfile` specifies the filename relative to the kubelet's seccomp root directory (`/var/lib/kubelet/seccomp/`). The profile file `deny-mkdir.json` is placed at that path, so `localhostProfile: "deny-mkdir.json"` correctly references it. This configuration blocks `mkdir` and `chmod` syscalls while allowing all others, as defined by the custom profile.

Answer

annotations:
  seccomp.security.alpha.kubernetes.io/pod: "localhost/deny-mkdir"

Answer

seccompProfile:
  type: localhost
  localhostProfile: "deny-mkdir.json"

Answer

seccompProfile:
  type: RuntimeDefault

Question 8

A pod in namespace 'secure' has the following securityContext:
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
The pod fails to start. The namespace is enforced with the 'restricted' Pod Security Standard. What is the most likely reason?

Accepted Answer

The pod adds capabilities, which is not allowed by the restricted policy.. The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.

Answer

The runAsUser is set to 1000, which is not allowed by the restricted policy.

Answer

The pod sets runAsNonRoot to true, which is not allowed by the restricted policy.

Answer

The pod drops all capabilities, which is not allowed by the restricted policy.

Question 9

An administrator wants to reduce the attack surface of a Kubernetes node by disabling unnecessary system services. Which of the following services is considered unnecessary on a dedicated Kubernetes worker node and can be safely disabled?

Accepted Answer

cups. (cups) is correct because CUPS (Common Unix Printing System) is a print service that is unnecessary on a dedicated Kubernetes worker node, which does not require printing capabilities. Disabling it reduces the attack surface by removing a potential vector for privilege escalation or remote exploitation, as CUPS historically has had vulnerabilities like CVE-2024-35235. On a worker node, only essential services for container runtime, orchestration, and system management should run.

Answer

containerd

Answer

sshd

Answer

kubelet

Question 10

Which TWO of the following are valid methods to apply a seccomp profile to a Kubernetes pod? (Select two.)

Accepted Answer

Using the pod annotation: seccomp.security.alpha.kubernetes.io/pod. The seccomp.security.alpha.kubernetes.io/pod annotation was the original method to apply a seccomp profile to an entire pod in Kubernetes versions prior to v1.19. This annotation specifies the seccomp profile path or type (e.g., 'runtime/default' or 'localhost/<profile>') for the pod's containers, and it remains valid in older clusters or when using legacy configurations.

Answer

Using the field: spec.seccompProfile

Answer

Using the command line flag: --seccomp-profile when running kubectl run

Answer

Using the pod annotation: container.seccomp.security.alpha.kubernetes.io

Question 11

Which TWO of the following are valid AppArmor profile modes? (Select two.)

Accepted Answer

complain. AppArmor has two primary profile modes: 'complain' (also known as 'learning' mode) and 'enforce' (also known as 'confined' mode). In complain mode, policy violations are logged but not blocked, allowing administrators to test profiles. In enforce mode, violations are both logged and blocked, actively enforcing the security policy.

Answer

kill

Answer

audit

Answer

permissive

Question 12

Which THREE of the following are best practices for minimizing host access from containers to reduce the attack surface? (Select three.)

Accepted Answer

Avoid setting hostPID to true. Setting hostPID to true allows a container to share the host's process ID namespace, enabling it to see all host processes and potentially access sensitive information or perform privilege escalation. Avoiding this setting reduces the attack surface by preventing containers from interacting with host-level processes, which is a key principle of namespace isolation in Kubernetes.

Answer

Disable swap on nodes

Answer

Avoid using hostPort in container port mappings

Question 13

A security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

Accepted Answer

Restricted. The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

Answer

Privileged

Answer

Custom

Answer

Baseline

Question 14

A cluster administrator wants to apply a custom seccomp profile located at '/var/lib/kubelet/seccomp/audit.json' to a pod. Which YAML snippet correctly configures the pod's security context to use this profile?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: audit.json. When using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` must specify only the filename (not the full path). Kubernetes automatically prepends the path `/var/lib/kubelet/seccomp/` to the filename, so `audit.json` resolves to the correct location.

Answer

seccompProfile:
  type: Unconfined
  localhostProfile: audit.json

Answer

seccompProfile:
  type: Localhost
  localhostProfile: /var/lib/kubelet/seccomp/audit.json

Answer

seccompProfile:
  type: RuntimeDefault
  localhostProfile: audit.json

Question 15

Which kubectl command is used to check the AppArmor status on a Kubernetes node?

Accepted Answer

kubectl node-shell <node> -- aa-status. `kubectl node-shell` provides a shell into the node's filesystem, allowing you to run `aa-status` directly on the node to check the AppArmor status. This is the standard method to verify AppArmor profiles and their enforcement state on a Kubernetes node, as AppArmor operates at the host kernel level and is not managed via the Kubernetes API.

Answer

kubectl describe node <node> | grep AppArmor

Answer

kubectl get apparmor

Answer

kubectl exec <pod> -- aa-status