EX200 Deploy, configure, and maintain systems Practice Question
A systems administrator installs a custom hardware device driver kernel module named 'mydevice' on a RHEL 9 system. The module is built and placed in /lib/modules/$(uname -r)/extra/. The administrator loads it manually with modprobe mydevice and it works. However, after a system reboot, the module is not loaded. The administrator checks that the device is present at boot time. Which step should be taken to ensure the module loads automatically at boot?
⚠ Common exam trap
It's easy for candidates to confuse the initramfs rebuild (dracut) with the simpler modules-load.d mechanism, thinking all kernel modules must be baked into the initramfs to load at boot, when in fact only modules needed before root is mounted require that treatment.
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 'echo mydevice > /etc/modules-load.d/mydevice.conf'
Writing the module name to a file in /etc/modules-load.d/ ensures systemd loads the module automatically at boot. The modules-load.d mechanism is the standard RHEL 9 method for specifying kernel modules to be loaded early in the boot process, before the root filesystem is fully available.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add the line 'install mydevice /sbin/modprobe --ignore-install mydevice' to /etc/modprobe.d/load.conf
Why it's wrong here
The install directive in modprobe.d redefines how modprobe brings a module into the kernel, but it is purely reactive: it executes only when modprobe is explicitly invoked or the kernel requests the module. At boot, nothing automatically calls modprobe for mydevice simply because this line exists, so no automatic load occurs. The --ignore-install flag prevents recursion but does not create a boot-time trigger, making this configuration ineffective for the stated goal.
- ✗
Rebuild the initramfs with 'dracut --force --add mydevice'
Why it's wrong here
Rebuilding the initramfs with dracut --force --add mydevice embeds the module and its dependencies into the early user-space image, but that only matters before the root filesystem is mounted. The driver already lives in /lib/modules, so after boot the standard kmod/udev mechanism can load it; adding it to initramfs supplies no instruction to load it on a running system. The --add option merely ensures the module is present in the initramfs, not that it is listed for automatic loading at boot, so the device still may not be initialized.
- ✗
Add the line 'load mydevice' to /etc/rc.local and ensure rc.local is executable.
Why it's wrong here
Adding the line 'load mydevice' to /etc/rc.local is ineffective for two reasons: the command name is wrong (the correct utility is modprobe), and rc.local is a legacy mechanism that systemd only runs if the unit is explicitly enabled, so it cannot be relied upon on modern RHEL systems. Even if it executed, it would run very late in the boot sequence, after the hardware probe and device initialization, so the driver would not be loaded when the device is first detected. Therefore this approach fails to provide the deterministic early loading that modular device support requires.
- ✓
Run 'echo mydevice > /etc/modules-load.d/mydevice.conf'
Why this is correct
Writing the module name to a file under /etc/modules-load.d/ is the canonical systemd way to force a kernel module to be loaded at boot. systemd-modules-load.service reads every .conf file in that directory during early boot and passes each line as a module name to modprobe, so 'mydevice' will be loaded reliably. The echo redirection creates the necessary file with the correct content, and because the service runs before most hardware-dependent services, the driver will be present when the device is probed.
Go deeper
Related to this question
About these practice questions
One of 127 original EX200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat 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 EX200 exam.