CKS System Hardening Practice Question
Which of the following is a valid way to check the status of AppArmor profiles on a node?
⚠ Common exam trap
Many exam-takers confuse Kubernetes-native resources (like `kubectl get`) with node-level security tools, or assume that reading a kernel file is equivalent to using the dedicated status command, but the exam expects familiarity with the standard Linux administration command `aa-status` for AppArmor.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
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 analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use 'apparmor_parser --status'
Why it's wrong here
apparmor_parser is a userspace tool for compiling and loading AppArmor profiles into the kernel, not for querying their runtime status. It has no --status flag; invoking it with such a flag produces an error. Profile status is obtained from the securityfs interface, not from the parser utility, so this command cannot reveal which profiles are active or their enforcement mode.
- ✗
Run 'kubectl get apparmorprofiles'
Why it's wrong here
kubectl get queries Kubernetes API resources, but AppArmor profiles are not Kubernetes objects; they exist as kernel-level policy on each node. Unless a bespoke CustomResourceDefinition were created to mirror them, kubectl would find no apparmorprofiles resource. Even if a CRD existed, it would reflect declarative state, not the live kernel status of AppArmor on the node.
- ✗
Read the file /sys/kernel/security/apparmor/profiles
Why it's wrong here
The file /sys/kernel/security/apparmor/profiles does list currently loaded profiles, so it is a legitimate kernel interface for inspecting them. However, it only provides raw profile names and modes, without the summarized, human-readable status that aa-status delivers, such as process mappings and profile counts. While reading it is not wholly wrong, aa-status is the standard diagnostic tool because it parses this interface and presents a comprehensive status view.
- ✓
Run 'aa-status' on the node
Why this is correct
aa-status is the canonical utility from the apparmor-utils package for checking AppArmor status on a node. It reads the AppArmor security filesystem under /sys/kernel/security/apparmor/ to display loaded profiles, their enforcement mode (enforce or complain), and which processes are confined. Running aa-status on the node gives an administrator the exact, current state of the AppArmor subsystem, making it the correct and most direct verification method.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.