CKS System Hardening Practice Test 6 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?

Accepted Answer

Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'. The 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Answer

Add a PodSecurityPolicy that sets seccomp to RuntimeDefault

Answer

Use a cronjob to audit and modify pods that do not have seccomp set

Answer

Add a seccomp profile to the kubelet configuration

Question 7

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/: localhost/my-custom-profile. The AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/` with the value `localhost/`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Answer

container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile

Answer

apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile

Answer

container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce

Question 8

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 9

A security auditor wants to ensure that no container in the cluster has the CAP_SYS_ADMIN capability. Which of the following is the most effective way to enforce this cluster-wide?

Accepted Answer

Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods. A mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

Answer

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Answer

Modify the kubelet to disallow CAP_SYS_ADMIN

Answer

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Question 10

Which of the following host access settings should be disabled to reduce the attack surface of a container?

Accepted Answer

hostPID: false. Setting `hostPID: false` explicitly disables the container's access to the host's process ID namespace, which reduces the attack surface by preventing the container from seeing or interacting with host processes. In Kubernetes, when `hostPID` is set to `true`, the container shares the host's PID namespace, allowing it to potentially escalate privileges or interfere with other workloads. Disabling this setting (i.e., `false`) is a recommended security best practice to enforce process isolation.

Answer

hostNetwork: true

Answer

hostPID: true

Answer

hostIPC: true

Question 11

Which TWO of the following are valid methods to apply a custom seccomp profile to a pod in Kubernetes?

Accepted Answer

Setting the annotation 'seccomp.security.alpha.kubernetes.io/pod' on the pod. The annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to 1.19. This annotation is still valid in older clusters or when using the alpha API, and it directly specifies the seccomp profile path or type for the pod.

Answer

Using 'securityContext.seccompProfile.type: RuntimeDefault' with 'localhostProfile' set

Answer

Configuring the kubelet with --seccomp-default-profile flag

Answer

Adding a seccomp profile to the container image and referencing it in the pod spec

Question 12

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes?

Accepted Answer

Minimize host access from containers (e.g., disable hostPID, hostNetwork). Option A is correct because disabling hostPID and hostNetwork prevents containers from sharing the node's process namespace and network stack, which blocks container escapes and lateral movement to host processes or interfaces. Option B is correct because minimal base images (e.g., distroless or Alpine) contain fewer packages, libraries, and utilities, shrinking the exploitable vulnerability surface inside the container. Option C is correct because disabling unnecessary system services on nodes (e.g., unused daemons, package managers, or listening ports) removes potential entry points and reduces the node's overall attack surface. Option D is incorrect because exposing the host network to containers increases risk by allowing direct access to node interfaces and services, which is the opposite of a hardening best practice. Option E is incorrect because running containers as root grants excessive privileges and makes privilege escalation or container breakout far more damaging; least-privilege non-root users are preferred.

Answer

Expose the host network to containers for better performance

Answer

Run containers as root to simplify permissions

Question 13

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Accepted Answer

AppArmor profiles can be loaded in 'enforce' or 'complain' mode. AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Answer

The profile name in the annotation should be just the profile name without the 'localhost/' prefix

Answer

The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

Answer

AppArmor profiles are automatically loaded from a ConfigMap

Question 14

An administrator wants to enforce that all pods in a namespace use the restricted Pod Security Standard. Which of the following commands correctly enables this enforcement?

Accepted Answer

kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards are enforced via labels on the namespace, and the `pod-security.kubernetes.io/enforce` label with value `restricted` tells the Pod Security Admission controller to reject any pod that violates the restricted policy. This is the only way to actively block non-compliant pods from being created in the namespace.

Answer

kubectl label namespace myns pod-security.kubernetes.io/audit=restricted

Answer

kubectl annotate namespace myns pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label namespace myns pod-security.kubernetes.io/warn=restricted

Question 15

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

Accepted Answer

Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities. It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Answer

Set securityContext.capabilities.drop: ['ALL'] with no add

Answer

Leave capabilities unset to use the default set

Answer

Add only the necessary capabilities without dropping