CKS System Hardening Practice Test 9 — 15 Questions

Question 1

A node in your cluster is running unnecessary services that increase the attack surface. Which of the following is the BEST approach to reduce the attack surface on the node?

Accepted Answer

Identify and disable unnecessary system services using systemctl or similar tools. The most direct way to reduce the attack surface on a node is to disable unnecessary services that are actively listening or running. Tools like `systemctl disable` or `systemctl stop` permanently turn off services such as `telnet`, `rpcbind`, or `cups`, which are common vectors for exploitation. Simply blocking ports with a firewall (A) leaves the service running and potentially exploitable via localhost or if the firewall is misconfigured, while AppArmor (D) confines but does not remove the service. NetworkPolicies (B) operate at the Kubernetes network layer and cannot control host-level services.

Answer

Use a firewall to block all ports except those required

Answer

Apply a NetworkPolicy to block traffic to the node

Answer

Use AppArmor to confine the services

Question 2

Which of the following is a valid way to check the status of AppArmor profiles on a node?

Accepted Answer

Run 'aa-status' on the node. `aa-status` is the standard command-line tool for checking the status of AppArmor profiles on a Linux node. It displays which profiles are loaded, which processes are confined, and the enforcement mode (enforce/complain). This is the direct, node-level utility for AppArmor status verification.

Answer

Use 'apparmor_parser --status'

Answer

Run 'kubectl get apparmorprofiles'

Answer

Read the file /sys/kernel/security/apparmor/profiles

Question 3

A container needs to run with the NET_ADMIN capability to modify network settings. The cluster enforces the baseline Pod Security Standard. Which securityContext configuration should be used?

Accepted Answer

capabilities:
  add: ["NET_ADMIN"]. Under the baseline Pod Security Standard (PSS), both options A and C are valid because the baseline profile permits adding specific capabilities like NET_ADMIN. Option A directly adds NET_ADMIN to the container's capabilities. Option C drops all capabilities first and then adds NET_ADMIN, which is also compliant because dropping all is allowed under baseline, and then adding NET_ADMIN is permitted. Option B uses an invalid field name (linuxCapabilities should be capabilities). Option D drops NET_ADMIN, which would remove the required capability.

Answer

linuxCapabilities:
  add: ["NET_ADMIN"]

Answer

capabilities:
  drop: ["NET_ADMIN"]

Question 4

Which of the following host access settings should be avoided to minimize the attack surface from containers? (Select the setting that increases risk the most.)

Accepted Answer

hostPID: true. Setting `hostPID: true` allows a container to share the host's process ID namespace, enabling it to see all processes running on the host. This breaks the fundamental isolation that containers should provide, giving a compromised container direct visibility into host processes and the ability to potentially interact with them (e.g., sending signals). This significantly increases the attack surface and is the most dangerous setting among the options.

Answer

securityContext:
  capabilities:
    drop: ["ALL"]

Answer

readOnlyRootFilesystem: true

Answer

resources:
  limits:
    memory: "512Mi"

Question 5

What is the purpose of the 'seccomp' feature in Kubernetes?

Accepted Answer

To restrict the system calls a container can make. Seccomp (secure computing mode) is a Linux kernel feature that allows a process to specify a filter for the system calls it can make. In Kubernetes, seccomp profiles can be applied to pods or containers to restrict the allowed syscalls, reducing the kernel attack surface. This is a key mechanism for container runtime security, distinct from filesystem, capability, or network controls.

Answer

To restrict file system access for a container

Answer

To restrict the Linux capabilities a container can use

Answer

To restrict network access for a container

Question 6

After deploying a pod with an AppArmor profile, the pod status shows 'ContainerCreating' for a long time and then fails. What is the most likely cause?

Accepted Answer

The AppArmor profile is not loaded on the node. When a pod remains in 'ContainerCreating' state and then fails, it often indicates that the node cannot apply the specified AppArmor profile. The most likely cause is that the profile referenced in the pod annotation (e.g., 'container.apparmor.security.beta.kubernetes.io/: localhost/') is not loaded into the node's kernel. Without the profile loaded, the container runtime (e.g., containerd or CRI-O) cannot enforce the policy, causing the pod creation to hang and eventually fail.

Answer

The AppArmor profile is not in the same namespace as the pod

Answer

The pod's securityContext does not have 'apparmor: enabled'

Answer

The node does not support AppArmor

Question 7

Which of the following is the correct way to drop all Linux capabilities for a container?

Accepted Answer

capabilities:
  drop: ["ALL"]. In a Kubernetes Pod security context, the `capabilities` field is a list of capabilities to add or drop. Dropping `ALL` removes all Linux capabilities from the container, which is the most restrictive and secure approach. The correct YAML syntax uses `capabilities:` (plural) with a `drop:` list containing `"ALL"`.

Answer

capability:
  drop: ["ALL"]

Answer

capabilities:
  drop: ["NET_RAW", "CHOWN"]

Answer

capabilities:
  add: ["ALL"]

Question 8

An administrator wants to prevent containers from using hostNetwork, hostPID, and hostIPC. Which Pod Security Standard level enforces these restrictions?

Accepted Answer

Restricted. Both the Baseline and Restricted Pod Security Standards prohibit the use of hostNetwork, hostPID, and hostIPC. The Restricted standard is the most stringent of the two, adding further constraints such as seccomp requirements and capability drops, but it is not the only level that enforces the listed namespace restrictions. The question is ambiguous unless it specifies 'most stringent'.

Answer

None; you must manually configure admission webhooks

Answer

Privileged

Question 9

Which THREE of the following are valid seccomp profile types in Kubernetes? (Select three.)

Accepted Answer

Localhost. The two correct options are A (Localhost) and B (RuntimeDefault). Option A is correct because the `Localhost` seccomp profile type allows you to reference a custom seccomp profile stored as a JSON file on the node's filesystem. This is a valid profile type in Kubernetes, specified via the `localhostProfile` field in the pod's security context. Option B is correct because `RuntimeDefault` is a valid seccomp profile type that instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile, which typically blocks a set of dangerous syscalls while allowing normal operations. Option D (Unconfined) is also a valid seccomp profile type in Kubernetes, but the question asks for exactly two answers, so only A and B are selected. Options C and E are not valid seccomp profile types.

Answer

RuntimeDefault

Answer

ContainerDefault

Answer

KubernetesDefault

Question 10

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes? (Select three.)

Accepted Answer

Use read-only root filesystems for containers where possible. Using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.

Answer

Allow privileged containers for debugging

Answer

Run containers as root to simplify management

Question 11

Which THREE of the following are restrictions enforced by the 'baseline' Pod Security Standard? (Select three.)

Accepted Answer

Host network access (hostNetwork) is not allowed. The 'baseline' Pod Security Standard (PSS) enforces several restrictions to provide a reasonable level of security without breaking most workloads. The three correct restrictions are:

- A: Host network access (hostNetwork) is not allowed. The baseline profile prohibits sharing host namespaces, including hostNetwork, to isolate pods from the host network.
- B: Capabilities must be limited to a minimal set. While the baseline profile does not require dropping all capabilities (drop: ["ALL"]), it prohibits adding dangerous capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, or CAP_SYS_PTRACE. This prevents escalation of privileges through capability misuse.
- D: Privilege escalation must be disabled (AllowPrivilegeEscalation: false). This is a baseline requirement to prevent processes from gaining more privileges than their parent.

Option C (seccomp profile must be set to RuntimeDefault or Localhost) and Option E (containers must run as non‑root) are both requirements of the 'restricted' profile, not the baseline. Therefore, they are incorrect selections.

Answer

Seccomp profile must be set to RuntimeDefault or Localhost

Answer

Containers must run as non-root (runAsNonRoot: true)

Question 12

Which TWO of the following are correct ways to apply a seccomp profile named 'audit.json' located on each node? (Select two.)

Accepted Answer

Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json. In Kubernetes v1.19+, the `securityContext.seccompProfile` field is the stable API for configuring seccomp profiles. Setting `type: Localhost` and `localhostProfile: audit.json` instructs the kubelet to load the profile from the node's local seccomp directory (typically `/var/lib/kubelet/seccomp/audit.json`). This is the recommended approach for applying a node-local seccomp profile to a pod or container.

Answer

Add annotation: seccomp.security.alpha.kubernetes.io/pod: audit.json

Answer

Add annotation per container: container.seccomp.security.alpha.kubernetes.io/<name>: localhost/audit.json

Answer

Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

Question 13

Which annotation is used to apply an AppArmor profile to a pod in Kubernetes?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The `container.apparmor.security.beta.kubernetes.io/` annotation is the exact key used to apply an AppArmor profile to a specific container within a pod. The value of this annotation specifies the profile name (e.g., `localhost/` or `runtime/default`), and it must be set on the Pod object before the pod is created, as AppArmor profiles cannot be applied to running containers.

Answer

security.alpha.kubernetes.io/apparmor

Answer

apparmor.kubernetes.io/default

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 14

An administrator wants to run a container that requires the SYS_TIME capability. Which field should be used in the securityContext to add this capability?

Accepted Answer

capabilities.add. The `capabilities.add` field in the `securityContext` is specifically designed to add Linux capabilities (such as `SYS_TIME`) to a container without granting full root privileges. This follows the principle of least privilege, allowing only the required capability to modify the system clock.

Answer

privileged: true

Answer

allowPrivilegeEscalation: true

Answer

capabilities.drop

Question 15

A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: "custom-profile.json". When using a custom seccomp profile stored in the default kubelet seccomp directory (`/var/lib/kubelet/seccomp/`), the `type` must be `Localhost` and the `localhostProfile` must be a relative path (just the filename). Kubernetes automatically prepends the default seccomp root path, so `custom-profile.json` resolves to `/var/lib/kubelet/seccomp/custom-profile.json`.

Answer

seccompProfile:
  type: Unconfined
  localhostProfile: "custom-profile.json"

Answer

seccompProfile:
  type: RuntimeDefault
  localhostProfile: "custom-profile.json"

Answer

seccompProfile:
  type: Localhost
  localhostProfile: "/var/lib/kubelet/seccomp/custom-profile.json"