CAS-004 Security Engineering Practice Question
A security engineer is implementing a secure boot process for a Linux server. The requirement is to ensure that only signed and trusted kernel modules can be loaded, preventing rootkits from persisting. Which mechanism should the engineer enable?
⚠ Common exam trap
The trap here is conflating Secure Boot with kernel module signing; Secure Boot only validates the boot chain, not modules loaded later, so it does not prevent unsigned module loading.
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
✓
Kernel module signing enforcement (module.sig_enforce=1).
Kernel module signing enforcement is the specific mechanism that requires all kernel modules to be signed with a trusted key before they can be loaded. When enabled via the module.sig_enforce=1 kernel parameter, the kernel rejects any module without a valid signature. This prevents rootkits that use kernel modules from persisting, as they cannot be loaded. UEFI Secure Boot, SELinux, and IMA provide related but distinct protections that do not directly enforce module signing at load time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Integrity Measurement Architecture (IMA) with appraisal.
Why it's wrong here
IMA with appraisal measures and verifies file integrity, including kernel modules, but it does not prevent the loading of unsigned modules at the kernel level. It can detect tampering but relies on a policy and may not block module loading in all configurations. Module signing enforcement is the direct mechanism to block unsigned modules.
- ✗
UEFI Secure Boot with a custom key enrollment.
Why it's wrong here
UEFI Secure Boot verifies the signature of the bootloader and the kernel, but it does not enforce module signing for kernel modules loaded after boot. It ensures the initial boot chain is trusted, but without additional configuration, unsigned modules could still be loaded later. Therefore, it alone does not meet the requirement.
- ✗
Linux Security Modules (LSM) with SELinux in enforcing mode.
Why it's wrong here
SELinux provides mandatory access control and can confine processes, but it does not verify the signature of kernel modules. An attacker with root could still load a malicious module if module signing is not enforced. SELinux is a complementary control but does not prevent unsigned module loading.
- ✓
Kernel module signing enforcement (module.sig_enforce=1).
Why this is correct
Enabling kernel module signing enforcement ensures that the kernel will only load modules that are signed with a trusted key. This prevents unsigned or malicious modules from being loaded, even by root, thus blocking rootkits that rely on kernel modules. This directly satisfies the requirement to allow only signed and trusted kernel modules.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CAS-005 question from scratch — 973 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA 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 CAS-005 exam.