LPIC-1 Devices, Filesystems and FHS Practice Question
Which TWO statements about udev rules are correct? (Choose two.)
⚠ Common exam trap
Many exam-takers confuse 'udevadm verify' with a real command, but the LPIC-1 exam tests knowledge of the actual udevadm subcommands, and 'verify' is not one of them.
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
✓
Custom udev rules should be placed in /etc/udev/rules.d/.
Option A is correct because locally administered custom udev rules belong in /etc/udev/rules.d/, which takes precedence over the distribution-supplied rules in /usr/lib/udev/rules.d/ and is the supported location for administrator-defined rules. Option D is correct because udev rules match devices using keys such as ATTRS{idVendor} and ATTRS{idProduct} (or ENV{ID_VENDOR_ID}/ENV{ID_MODEL_ID} from the hardware database), allowing rules to target specific USB vendor and product IDs. Option B is wrong because udev processes events dynamically whenever devices are added or removed at runtime, not only at boot. Option C is wrong because udev is a device manager for the kernel device model and has no scheduling capability; periodic tasks are handled by cron or systemd timers. Option E is wrong because there is no 'udevadm verify' subcommand; syntax checking is done with 'udevadm test' or 'udevadm test-builtin', while 'udevadm control --reload' reloads rules.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Custom udev rules should be placed in /etc/udev/rules.d/.
Why this is correct
Placing custom rules in /etc/udev/rules.d/ satisfies the requirement for persistent, administrator-defined device naming that survives package upgrades. Files here are parsed before /usr/lib/udev/rules.d/, so local rules take precedence, and the directory is reserved for local administration rather than vendor-supplied defaults.
- ✗
Udev rules are only applied at boot time.
Why it's wrong here
udev rules are evaluated whenever a device event occurs, including hotplug insertion at runtime, so restricting them to boot time misses most device handling. It is tempting because rules do load during early boot, but that is only the initial trigger, not the sole one.
- ✗
Udev rules can be used to schedule periodic tasks via cron.
Why it's wrong here
Udev rules react to device events, not time schedules; periodic tasks belong to cron or systemd timers. It tempts because both manage system behaviour, yet udev triggers on kernel uevents such as device addition, not on clock intervals.
- ✓
Rules can match on attributes such as vendor ID and product ID.
Why this is correct
udev rules match device properties through keys such as ATTRS{idVendor} and ATTRS{idProduct}, letting rules target specific hardware regardless of the kernel-assigned device node name. This satisfies the scenario's requirement that rules can match on vendor and product identifiers.
- ✗
The 'udevadm verify' command tests rule syntax.
Why it's wrong here
No 'udevadm verify' subcommand exists; syntax checking is performed with 'udevadm test' or by reloading rules and observing errors. It tempts because verification commands exist in other tools, but udevadm offers test, info, trigger, and control instead.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-1 question from scratch — 402 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-1 practice question is part of Courseiva's free LPI 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 LPIC-1 exam.