CKS System Hardening Practice Test 11 — 15 Questions

Question 1

An administrator wants to drop all capabilities for a container and then add back only NET_BIND_SERVICE. Which securityContext configuration is correct?

Accepted Answer

capabilities:
  drop: ["ALL"]
  add: ["NET_BIND_SERVICE"]. It first drops all capabilities using `drop: ["ALL"]`, which removes every Linux capability from the container, and then explicitly adds back only `NET_BIND_SERVICE`. This follows the principle of least privilege: start with no capabilities and grant only what is needed. The `securityContext` in Kubernetes applies these settings at the container level, ensuring the container can bind to privileged ports (below 1024) without any other elevated permissions.

Answer

capabilities:
  add: ["NET_BIND_SERVICE"]

Answer

capabilities:
  drop: ["ALL"]

Answer

capabilities:
  drop: ["NET_BIND_SERVICE"]
  add: ["ALL"]

Question 2

Which tool is used to load AppArmor profiles on a node?

Accepted Answer

apparmor_parser. The `apparmor_parser` tool is the standard utility for loading AppArmor profiles into the kernel's security module. It reads profile definitions from text files, compiles them into binary form, and loads them into the kernel's LSM (Linux Security Module) subsystem. Without this tool, AppArmor profiles cannot be activated on a node.

Answer

aa-enforce

Answer

aa-status

Answer

kubectl apply

Question 3

What is the default seccomp profile for Kubernetes containers when no seccompProfile is specified?

Accepted Answer

RuntimeDefault. When no `seccompProfile` is specified in the Pod or container security context, Kubernetes applies the `RuntimeDefault` seccomp profile by default. This profile is defined by the container runtime (e.g., containerd or CRI-O) and blocks a specific set of syscalls that are considered dangerous or unnecessary for containers, while allowing normal application operations. This default behavior was introduced in Kubernetes 1.19 and became the default for all pods in Kubernetes 1.22, enhancing security without requiring explicit configuration.

Answer

Localhost

Answer

No profile is applied

Answer

Unconfined

Question 4

A pod runs with 'hostNetwork: true' and 'hostPID: true'. Which security concern is MOST directly increased?

Accepted Answer

The container can access host processes and potentially escape. Setting `hostNetwork: true` and `hostPID: true` in a pod grants the container direct access to the host's network namespace and process namespace. With `hostPID: true`, the container can see all host processes (e.g., via `ps aux`) and potentially interact with them using system calls like `ptrace`, which could allow escaping the container by injecting code into a host process. This combination directly increases the risk of container breakout, making A the most significant security concern.

Answer

The container can modify iptables rules

Answer

The container can sniff network traffic of other pods

Answer

The container can mount the host filesystem

Question 5

An administrator creates a custom seccomp profile and places it at /var/lib/kubelet/seccomp/myprofile.json. Which securityContext field is used to apply this profile to a container?

Accepted Answer

seccompProfile:
  type: Localhost
  localhostProfile: "myprofile.json". When using a custom seccomp profile stored on the node, the `type` must be `Localhost`, and the `localhostProfile` field must contain only the filename (e.g., `myprofile.json`), not the full path. Kubernetes automatically prepends `/var/lib/kubelet/seccomp/` to the filename, so specifying the full path would cause the profile to be looked up in the wrong location, resulting in a failure to apply the profile.

Answer

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

Answer

seccompProfile:
  type: RuntimeDefault
  localhostProfile: "myprofile.json"

Answer

seccompProfile:
  type: Unconfined
  localhostProfile: "myprofile.json"

Question 6

Which TWO of the following are valid Pod Security Standards levels?

Accepted Answer

privileged. The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. 'Privileged' is the most permissive level, allowing all known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources.

Answer

secure

Answer

default

Answer

strict

Question 7

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Accepted Answer

Disable unnecessary system services on nodes. Disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.

Answer

Open all ports on nodes to allow easy debugging

Answer

Run all containers as root user

Question 8

A cluster administrator wants to enforce that all pods in the 'restricted' namespace use the Restricted Pod Security Standard. Which command achieves this?

Accepted Answer

kubectl label ns restricted pod-security.kubernetes.io/enforce=restricted. The `kubectl label` command with the key `pod-security.kubernetes.io/enforce` and value `restricted` applies the Restricted Pod Security Standard to the namespace. This label instructs the Pod Security Admission controller to enforce the most restrictive policy, rejecting any pod that violates the standard. The command targets the namespace 'restricted' as required.

Answer

kubectl annotate ns restricted pod-security.kubernetes.io/restricted=restricted

Answer

kubectl label ns restricted pod-security.kubernetes.io/enforce=privileged

Answer

kubectl create podsecuritypolicy restricted --namespace restricted

Question 9

You have built a custom seccomp profile at /var/lib/kubelet/seccomp/audit.json. Which YAML snippet correctly applies this profile to a container?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: "audit.json". The seccomp profile is stored at `/var/lib/kubelet/seccomp/audit.json`. The `localhostProfile` field expects a relative path from the base directory `/var/lib/kubelet/seccomp/`. Therefore, `audit.json` correctly resolves to the full path. The `seccompProfile` API with `type: Localhost` is the current method for applying custom profiles.

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault

Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: "profiles/audit.json"

Answer

securityContext:
  seccomp:
    type: Localhost
    profile: "audit.json"

Question 10

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor provides exactly two operational modes for a profile: enforce (option A) and complain (option B). In enforce mode, the profile's rules are actively applied and any access that violates the policy is denied and logged, which is the default mode for loaded profiles. In complain mode, violations are not blocked but are instead logged as complaints, allowing administrators to test and refine a profile before enforcing it. The other options are not AppArmor modes: audit (C) is not a mode but rather a logging facility/flag, allow (D) is not an AppArmor mode (it resembles SELinux terminology or a policy rule action), and unconfined (E) describes a process with no profile attached, not a selectable profile mode.

Answer

audit

Answer

allow

Answer

unconfined

Question 11

A Pod must be prevented from reading or writing to its container root filesystem. The application only writes to an emptyDir mount at /tmp. Which securityContext field should be set in the Pod specification to enforce this at the container level?

Accepted Answer

readOnlyRootFilesystem: true. The readOnlyRootFilesystem field in the container securityContext mounts the root filesystem as read-only, directly preventing writes. Other securityContext fields such as privileged, allowPrivilegeEscalation, and runAsNonRoot improve container isolation but do not restrict filesystem writability. Mounting a writable emptyDir at /tmp allows the application to continue writing to the required path while the rest of the root filesystem remains immutable.

Answer

runAsNonRoot: true

Answer

privileged: false

Answer

allowPrivilegeEscalation: false

Question 12

A Kubernetes cluster uses containerd as the container runtime. The security team wants to restrict a specific container so it cannot create raw network packets. The container image runs as root and the Pod specification does not drop any capabilities. Which Linux capability should be dropped from the container's securityContext to prevent raw packet creation while still allowing binding to privileged ports?

Accepted Answer

NET_RAW. The NET_RAW capability is what allows a process to create raw sockets and craft raw network packets. Dropping NET_RAW from the container's securityContext removes this ability while preserving NET_BIND_SERVICE so the container can still bind to privileged ports. This is the least-privilege approach: it targets exactly the unwanted capability without removing unrelated networking permissions.

Answer

NET_BIND_SERVICE

Answer

SYS_ADMIN

Answer

NET_ADMIN

Question 13

An administrator needs to apply a seccomp profile to a Pod. The profile is defined in a file named audit.json located on each node at /var/lib/kubelet/seccomp/profiles/audit.json. The cluster is running Kubernetes 1.25. Which seccomp type should be used in the Pod's securityContext to reference this profile?

Accepted Answer

Localhost. To use a custom seccomp profile stored on the node, the seccomp type must be set to Localhost, and the localhostProfile field must specify the path relative to the kubelet's seccomp root directory. RuntimeDefault uses a predefined profile, Unconfined disables seccomp, and DockerDefault is not a valid Kubernetes seccomp type. Therefore, Localhost is the correct choice.

Answer

Unconfined

Answer

RuntimeDefault

Answer

DockerDefault

Question 14

A security engineer is hardening a cluster and wants to reduce the attack surface of Pods by restricting their access to host resources. The engineer is reviewing a Pod specification and plans to remove or disable settings that grant host-level access. Which two settings should the engineer remove or set to false to reduce the attack surface? (Choose two.)

Accepted Answer

hostPID: true. The hostNetwork and hostPID fields, when set to true, place the Pod in the host's network and PID namespaces respectively, giving it direct access to host resources and significantly increasing the attack surface. Removing or setting these to false isolates the Pod. The other options either represent secure settings that are already in place or address different security concerns not directly related to host resource access.

Answer

allowPrivilegeEscalation: true

Answer

readOnlyRootFilesystem: false

Answer

privileged: false

Question 15

A Pod is being deployed with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000. The container image's files are owned by root:root with permissions 755. The application needs to write to a directory /data that is mounted as an emptyDir volume. What will happen when the container attempts to write to /data?

Accepted Answer

The write will fail with a permission denied error because the emptyDir volume is owned by root and the container runs as user 1000.. An emptyDir volume is created with root:root ownership and 0755 permissions by default. The container runs as user 1000 and group 3000, which are not the owner and do not have write permission on the volume root. Unless a fsGroup is specified to change the group ownership and permissions, the write will fail with a permission denied error. The other options incorrectly assume automatic writability or misattribute the cause.

Answer

The write will fail because emptyDir volumes are read-only by default.

Answer

The write will succeed because runAsUser and runAsGroup automatically change the ownership of mounted volumes.

Answer

The write will succeed because emptyDir volumes are always writable by any user.