CKS System Hardening Practice Test 7 — 15 Questions

Question 1

Which of the following is the correct annotation to apply an AppArmor profile named 'my-profile' to a container named 'app' in a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile. The AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/: localhost/`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Answer

security.alpha.kubernetes.io/apparmor/app: localhost/my-profile

Answer

pod.apparmor.security.beta.kubernetes.io/app: my-profile

Answer

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

Question 2

A pod is running with a custom seccomp profile located at /var/lib/kubelet/seccomp/my-profile.json. Which securityContext configuration correctly applies this profile?

Accepted Answer

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

Answer

seccompProfile: { type: RuntimeDefault }

Answer

seccompProfile: { type: Localhost, localhostProfile: /var/lib/kubelet/seccomp/my-profile.json }

Answer

seccompProfile: { type: Unconfined }

Question 3

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

Accepted Answer

PSP support was removed from Kubernetes in 1.25. PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Answer

The PSP API version needs to be updated to v1

Answer

PSPs were replaced by NetworkPolicies in 1.25

Answer

The PSP was not applied to the correct namespace

Question 4

Which command is used to check whether AppArmor is enabled and which profiles are loaded on a Linux node?

Accepted Answer

aa-status. AppArmor is a Linux Security Module (LSM) enforced at the node level, not a Kubernetes resource. Kubernetes does not expose AppArmor status via kubectl. To check whether AppArmor is enabled and which profiles are loaded, you must execute `aa-status` directly on the node (e.g., via SSH). This command queries the AppArmor kernel module and lists all loaded profiles.

Answer

kubectl get seccomp

Answer

kubectl get apparmor

Answer

systemctl status apparmor

Question 5

A pod has the following security context: capabilities: { drop: ['ALL'] } and privileged: false. The pod fails to start because it requires the ability to run iptables commands. Which of the following should be added to the pod's security context?

Accepted Answer

capabilities: { add: ['NET_ADMIN'] }. The pod needs to run iptables commands, which require the NET_ADMIN capability. Since the security context drops ALL capabilities, you must explicitly add NET_ADMIN back. Option D correctly adds NET_ADMIN, granting the necessary network administration privileges without making the container fully privileged.

Answer

privileged: true

Answer

capabilities: { add: ['SYS_ADMIN'] }

Answer

capabilities: { drop: ['NET_ADMIN'] }

Question 6

Which of the following fields in a PodSecurityPolicy (or Pod Security Standards) prevents a container from running as root?

Accepted Answer

runAsUser: MustRunAsNonRoot. `runAsUser: MustRunAsNonRoot` in a PodSecurityPolicy (or the equivalent Pod Security Standard `restricted` profile) enforces that the container's user ID (UID) must not be 0 (root). This directly prevents the container from running as root, as the security context will reject any pod that specifies `runAsUser: 0` or omits the field when the policy requires a non-root user.

Answer

runAsUser: RunAsAny

Answer

runAsGroup: MustRunAsNonRoot

Answer

seLinuxContext: MustRunAsNonRoot

Question 7

A security auditor wants to verify that the AppArmor profile 'my-profile' is in enforce mode on a running container. Which command should they run inside the node?

Accepted Answer

cat /proc//attr/current. The file `/proc//attr/current` contains the current AppArmor confinement status for a given process. Reading this file for a container's PID inside the node will show the profile name and mode (e.g., `my-profile (enforce)`), directly confirming that the profile is in enforce mode.

Answer

dmesg | grep apparmor

Answer

apparmor_parser -r my-profile

Answer

cat /proc/<pid>/environ

Question 8

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

Accepted Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }. The AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Answer

annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }

Answer

annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }

Question 9

A pod is configured with securityContext: { seccompProfile: { type: RuntimeDefault } }. Which of the following is true about this configuration?

Accepted Answer

The pod uses the default seccomp profile provided by the container runtime. Setting `seccompProfile.type: RuntimeDefault` in the pod's securityContext instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile, which is typically a restrictive profile that blocks a large set of syscalls. This is the recommended approach for enabling seccomp without needing to define a custom profile, and it is available in Kubernetes v1.19+.

Answer

The pod uses a custom seccomp profile

Answer

Seccomp is disabled for the pod

Answer

The pod must have CAP_SYS_ADMIN to use this setting

Question 10

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

Accepted Answer

apparmor_parser my-profile. The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Answer

apparmor_load my-profile

Answer

apparmor_parser -R my-profile

Answer

systemctl start apparmor my-profile

Question 11

A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?

Accepted Answer

Create a custom seccomp profile that allows the syscall and apply it via type: Localhost. The default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Answer

Use the RuntimeDefault profile and add capabilities

Answer

Change the seccomp profile to another runtime default

Answer

Set seccompProfile to Unconfined

Question 12

Which TWO of the following are valid ways to reduce the attack surface of a Kubernetes node? (Select 2)

Accepted Answer

Restrict hostNetwork, hostPID, and hostIPC access from containers. Option B is correct because restricting hostNetwork, hostPID, and hostIPC prevents containers from sharing the node's network, process, and IPC namespaces, which blocks container escapes and privilege escalation that would otherwise expose the host directly. Option D is correct because disabling unnecessary system services on the node removes unused daemons and listening ports, shrinking the exploitable attack surface in line with CIS Kubernetes Benchmark node hardening guidance. Option A is wrong because loading all kernel modules increases the attack surface by exposing additional kernel code and potential vulnerabilities rather than reducing it. Option C is wrong because enabling SSH for all users broadens remote access and credential exposure instead of limiting it. Option E is wrong because allowing containers to run as root grants unnecessary privileges that can be leveraged to compromise the node.

Answer

Load all kernel modules to support any workload

Answer

Enable SSH access for all users for troubleshooting

Answer

Allow containers to run as root

Question 13

Which TWO of the following are valid Pod Security Standard levels? (Select 2)

Accepted Answer

privileged. The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Answer

medium

Answer

high

Answer

default

Question 14

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Accepted Answer

Seccomp can be configured using the securityContext.seccompProfile field. The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Answer

Seccomp profiles can only be applied to privileged containers

Answer

Seccomp can only restrict system calls, not allow them

Question 15

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

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/`, where `` is the name of the container. This annotation, which was introduced in Kubernetes v1.4 as a beta feature, tells the kubelet to apply the referenced AppArmor profile (e.g., `localhost/k8s-apparmor-example`) to the specified container during runtime.

Answer

apparmor.security.kubernetes.io/profile

Answer

security.kubernetes.io/apparmor

Answer

seccomp.security.alpha.kubernetes.io/pod