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.

• ✓

  apparmor_parser

  Why this is correct

  apparmor_parser is the standard userspace tool that reads AppArmor policy text files, compiles them into the kernel's binary policy format, and sends them to the AppArmor LSM via the securityfs interface (typically mounted at /sys/kernel/security/apparmor). Flags such as -r (replace) and -a (add) control whether an existing profile is overwritten or a new one is inserted, making this the definitive tool for loading or updating profiles on a node. Without a successful apparmor_parser invocation, no AppArmor profile is active in the kernel, regardless of any other tools.

• ✗

  aa-enforce

  Why it's wrong here

  aa-enforce is not a profile-loading tool; it is a convenience utility in the apparmor-utils suite that flips already-loaded profiles between enforcement and complain mode by toggling symbolically linked profile files (e.g., adding a 'force' suffix). It does not parse profile source files or communicate with the kernel to add new policy, so it cannot be used to load a profile into AppArmor from scratch. The actual kernel loading is always performed by apparmor_parser, even when aa-enforce wraps a profile change.

• ✗

  aa-status

  Why it's wrong here

  aa-status is a read-only diagnostic utility that queries the AppArmor module (via /sys/module/apparmor/parameters and securityfs) to list currently loaded profiles and report which processes are confined. It performs no writes to the kernel's policy store and has no ability to parse profile text or insert new rules; its output can confirm whether a profile was loaded, but it is not the mechanism that loads it. Checking aa-status after using apparmor_parser is a common verification step, which itself shows these tools have distinct roles.

• ✗

  kubectl apply

  Why it's wrong here

  kubectl apply submits Kubernetes manifests to the API server to create or update cluster resources like Pods, Deployments, or custom resources; it operates entirely within the Kubernetes control plane and has no direct access to a node's host filesystem or the kernel LSM. AppArmor profiles must physically exist on each node—usually under /etc/apparmor.d—and be loaded by apparmor_parser before kubelet schedules pods that reference them via the container.apparmor.security.beta.kubernetes.io annotation or the apparmor.security.beta.kubernetes.io field. Merely applying a manifest that declares a profile does not install or load that profile onto any node; it only tells kubelet that a pre-loaded profile name should be enforced.

Go deeper

Related to this question