CKS System Hardening Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The container is privileged

  Why it's wrong here

  AppArmor confinement is independent of the container's privilege level; AppArmor operates at the kernel LSM layer and constrains processes based on the profile attached to the executable or the container runtime's profile, not on Linux capabilities or privilege flags. Even with CAP_SYS_ADMIN or privileged mode, the kernel checks AppArmor policy on security-relevant operations, so a loaded enforcing profile would still deny or restrict actions. Thus this cannot explain why the profile is not being enforced.

• ✓

  The profile was loaded in complain mode using apparmor_parser with the -C flag

  Why this is correct

  AppArmor profiles have two modes: enforce and complain. The `apparmor_parser` with `-C` (or `--complain`) loads the profile into complain mode, where violations are logged via audit but not blocked. If a pod's profile was loaded in complain mode, the kernel allows the denied operations while recording them, so the pod appears to run without AppArmor enforcement even though the profile is actively attached. This precisely matches the symptom: the profile is loaded but not enforcing.

• ✗

  The pod's securityContext sets allowPrivilegeEscalation to true

  Why it's wrong here

  allowPrivilegeEscalation controls the `no_new_privs` flag and prevents processes from gaining more privileges via setuid binaries or similar, but it is orthogonal to mandatory access control (MAC) systems like AppArmor. AppArmor still applies to the container's processes regardless of this setting; even if allowPrivilegeEscalation is false, an enforcing AppArmor profile would restrict system calls and file accesses. Therefore setting it to true does not disable AppArmor; it merely permits the container to escalate privileges, which is a different security mechanism and does not affect LSM policy enforcement.

• ✗

  The annotation is incorrectly formatted

  Why it's wrong here

  The annotation format is actually correct: container.apparmor.security.beta.kubernetes.io/<container-name> with value localhost/<profile-name>. AppArmor is enabled and the node has the profile; an incorrectly formatted annotation would cause Kubernetes to reject the pod or log an error, not silently skip enforcement. Since the annotation is well-formed and the pod runs, the format is not the issue; the actual cause lies in how the profile was loaded, not in the annotation syntax.

Go deeper

Related to this question