What the LPIC-2 exam covers
- 201: Capacity Planning88 questions
- 201: Linux Kernel168 questions
- 201: System Startup102 questions
- 201: Filesystems and Storage132 questions
- 201: Networking Configuration105 questions
- 201: System Maintenance25 questions
- 202: DNS59 questions
- 202: Web Services51 questions
- 202: File Sharing32 questions
- 202: Network Client Management13 questions
- 202: E-Mail Services9 questions
- 202: System Security33 questions
Free LPIC-2 practice test questions
A sample of 10 questions with answers and explanations. A free account includes a fixed set of 20 practice questions for this exam, retryable anytime. Paid access unlocks the full 817-question bank.
-
Which file/tool configures persistent DNS resolvers and search domains (traditionally)?
- A/etc/nsswitch.conf (name service switch source order)
- B/etc/hosts (static name-to-IP mappings)
- C/etc/host.conf (legacy resolver ordering)
- D/etc/resolv.conf (often managed by systemd-resolved/NetworkManager)Correct
✓ Correct answer: D/etc/resolv.conf is the traditional resolver configuration file holding nameserver lines for upstream DNS servers and a search directive for default domains appended to bare hostnames; on modern systems it is frequently a symlink generated by systemd-resolved or NetworkManager.
Why the other options are wrong- Ansswitch.conf sets the order of lookup sources (files, dns), not the resolver addresses themselves.
- B/etc/hosts holds static host-to-IP entries, not DNS server addresses or search domains.
- Chost.conf is a legacy resolver-ordering file and does not define nameservers or search domains.
-
SSH key-based login suddenly stops working for a user and falls back to a password prompt. The server's auth log shows: ``` Authentication refused: bad ownership or modes for directory /home/user/.ssh ``` What fixes it?
- Arestart sshd with systemctl restart sshd so the daemon reloads the authorized keys
- Badd the key again with ssh-copy-id to refresh it
- Cset StrictModes no in sshd_config to ignore the modes
- Dcorrect the permissions/ownership so ~/.ssh is 700 and authorized_keys is 600, owned by the userCorrect
✓ Correct answer: Dsshd refuses key authentication if the home/.ssh directory or authorized_keys are group- or world-writable or owned by the wrong user (StrictModes). Setting ~/.ssh to 700 and authorized_keys to 600, both owned by the user, satisfies the ownership and mode checks so key login resumes; the auth-log message states this exact cause.
Why the other options are wrong- Asshd reads authorized_keys per connection, so a restart changes nothing about a permissions refusal.
- BRe-copying the key does not fix the underlying bad ownership/modes on ~/.ssh.
- CDisabling StrictModes hides the problem instead of correcting the insecure permissions.
-
A vmstat 1 capture over several minutes shows the 'b' column consistently holding a value of 5 or 6 while 'r' stays near 0 and CPU 'id' (idle) stays above 70%. What does the 'b' column indicate is happening?
- ASeveral processes are blocked in uninterruptible sleep waiting on I/O, so the bottleneck is I/O latency rather than CPUCorrect
- BSeveral processes are runnable and queued for a CPU time slice, so the bottleneck is CPU contention here
- CSeveral processes are stopped after receiving SIGSTOP and are waiting to be resumed
- DSeveral processes are being swapped in from disk, so the bottleneck is memory pressure
✓ Correct answer: AIn vmstat's procs section the 'b' column counts processes in uninterruptible sleep, which on Linux almost always means they are waiting for I/O (disk or sometimes network/NFS) to complete. A persistently high 'b' with a near-zero run queue (r) and abundant idle CPU is the classic signature of an I/O-bound workload: the processors have spare capacity but tasks cannot proceed because storage is the limiting resource. The fix is to investigate disk throughput and latency, not to add CPU.
Why the other options are wrong- BRunnable-and-queued processes appear in the r column, not the b column, and r stays near 0 here.
- CStopped (T-state) processes are not counted in vmstat's b column, which tracks I/O-blocked tasks.
- DProcesses being swapped in from disk would show in the si column of vmstat, not the b column, which reflects uninterruptible I/O waits.
-
On a Debian system, an administrator wants a specific module, e1000e, to be included in every generated initramfs, not only when the running system happens to need it. Where should the module name be added so update-initramfs picks it up?
- AAdd a line 'e1000e' to /etc/initramfs-tools/modulesCorrect
- BAdd 'e1000e' to /etc/modprobe.d/initramfs.conf
- Cadd 'force_drivers+=" e1000e "' to /etc/dracut.conf.d/10-net.conf
- DAdd 'e1000e' to /boot/initrd.img-modules.list
✓ Correct answer: AThe /etc/initramfs-tools/modules file is the documented place on Debian/Ubuntu to list extra kernel modules that must always be copied into the initramfs, one module name per line (optional parameters allowed). After editing it, you run update-initramfs -u so the new image embeds the module and its dependencies. This is used when the auto-detection (in MODULES=dep mode) would otherwise omit a driver that is actually needed early. It works regardless of whether the module is currently loaded.
Why the other options are wrong- Badd 'e1000e' to /etc/modprobe.d/initramfs.conf is incorrect because modprobe.d files control module options, aliases, and blacklisting, not which modules are packed into the initramfs.
- Cadd 'force_drivers+=" e1000e "' to /etc/dracut.conf.d/10-net.conf is incorrect because force_drivers and dracut.conf.d belong to dracut, which is not the initramfs generator on Debian.
- Dadd 'e1000e' to /boot/initrd.img-modules.list is incorrect because no such configuration file exists; /boot holds the built images, and the module list lives under /etc/initramfs-tools.
-
A systemd system dropped to the emergency shell because the root filesystem is dirty and root is mounted read-only. You intend to run fsck on the root device safely. Which TWO statements about performing this repair correctly are accurate? (Choose TWO)
- AIt is safe to run fsck on the root device while it stays mounted read-only, because no writes occur underneath the checkCorrect
- BAfter fsck reports the filesystem clean, you should reboot so root is remounted read-write cleanlyCorrect
- CYou must first remount the root filesystem read-write so that fsck has permission to modify it
- DYou should unmount the root filesystem with 'umount /' before running fsck
✓ Correct answer: A, BThe emergency shell keeps root mounted read-only, which is the safe state for checking the root device directly with fsck since no concurrent writes can corrupt the structures it is repairing. Once the check completes and reports the filesystem clean, rebooting causes systemd to remount root read-write through the normal boot path, ensuring a consistent final state. Together these describe the correct recovery procedure for a dirty root device that cannot be unmounted.
Why the other options are wrong- Cfsck writes to the block device directly, and a read-write mount is what makes running it unsafe.
- DYou should unmount the root filesystem with 'umount /' is incorrect because the root filesystem is in use as the running system's root and cannot be unmounted; that is precisely why it must be checked while read-only or from external media.
-
What is the highest-priority directory in which an administrator should place custom udev rules so they override distribution-supplied defaults?
- A/lib/udev/rules.d/
- B/etc/udev/rules.d/Correct
- C/run/udev/rules.d/
- D/usr/lib/udev/rules.d/
✓ Correct answer: Budev collects rule files from /lib/udev/rules.d/, /run/udev/rules.d/, and /etc/udev/rules.d/, then sorts them by filename across all directories. When two files share the same name, the one in /etc/udev/rules.d/ takes precedence over /run and over /lib, making /etc the correct place for administrator overrides. Local custom rules therefore belong in /etc/udev/rules.d/.
Why the other options are wrong- A/lib/udev/rules.d/ is incorrect because it holds package-supplied default rules and a file there is overridden by an identically named file in /etc.
- C/run/udev/rules.d/ is incorrect because it is for volatile runtime-generated rules that do not persist across reboots and is lower priority than /etc.
- D/usr/lib/udev/rules.d/ is incorrect because on systems that use it, it serves the same role as /lib/udev/rules.d/ for vendor defaults and is still overridden by /etc.
-
After enabling TLS, an administrator runs "apachectl configtest" and gets "Invalid command 'SSLEngine', perhaps misspelled or defined by a module not included in the server configuration." Apache otherwise starts normally over HTTP. What is the most likely cause?
- Amod_ssl is not loaded (the LoadModule ssl_module line is missing or commented out)Correct
- Bmod_socache_shmcb is not loaded, so the SSL session cache module is unavailable
- CThe SSLEngine directive was placed outside any <VirtualHost> block
- DThe Listen 443 directive is missing from the main configuration
✓ Correct answer: AThe "Invalid command" error with the hint "defined by a module not included" is Apache's standard message when a directive belongs to a module that has not been loaded. SSLEngine and all other SSL* directives are provided by mod_ssl, so the LoadModule ssl_module modules/mod_ssl.so line must be active. On Debian/Ubuntu this is enabled with a2enmod ssl; on RHEL it requires installing mod_ssl. Once the module loads, configtest will recognize the directive.
Why the other options are wrong- Bmod_socache_shmcb only backs the SSL session cache; the SSLEngine directive itself is provided by mod_ssl, whose absence causes 'Invalid command'.
- CMisplacing SSLEngine would give a different context error, not 'Invalid command', which specifically means the module defining it is not loaded.
- DA missing Listen 443 would prevent binding the port, not make SSLEngine an unrecognized command; that error means mod_ssl is not loaded.
-
Two drop-in files set the same key. /run/sysctl.d/50-foo.conf sets net.core.somaxconn=1024, /etc/sysctl.d/50-foo.conf sets it to 2048, and /usr/lib/sysctl.d/50-foo.conf sets it to 512. After 'sysctl --system', which value wins, and why?
- A2048, because for identically named files /etc takes precedence over /run, which takes precedence over /usr/libCorrect
- B1024, because /run is volatile and is always applied last
- C512, because /usr/lib holds the vendor defaults that override administrator files
- DAll three are applied in directory order, so the last directory processed (/usr/lib) wins with 512
✓ Correct answer: Asysctl --system (like systemd's drop-in handling) merges files from /etc/sysctl.d, /run/sysctl.d, and /usr/lib/sysctl.d. Files are processed in lexicographic order of their basename across all directories, but when the SAME basename exists in more than one directory, the one in the higher-priority directory masks the others: /etc beats /run beats /usr/lib. Here all three are named 50-foo.conf, so only the /etc version is read and 2048 is applied. This precedence lets administrators (/etc) override both runtime-generated (/run) and vendor-shipped (/usr/lib) defaults.
Why the other options are wrong- BApplication order within a single key is by directory priority for same-named files, not 'volatile applied last'; /run does not win over /etc.
- C/usr/lib is the LOWEST priority (vendor defaults), so it is the one that gets overridden, not the one that overrides.
- DSame-named files are not all applied; only the highest-priority directory's copy is read, and processing is not a simple alphabetical directory sweep that lets /usr/lib win.
-
An administrator wants to scan for nearby wireless access points on interface wlan0 and list their ESSIDs, channels, and signal levels using the modern nl80211-based tool. Which command performs the scan?
- Aiw dev wlan0 scanCorrect
- Biw dev wlan0 link
- Ciw dev wlan0 info
- Diw phy phy0 channels
✓ Correct answer: AThe iw tool is the modern replacement for wireless-tools and uses the nl80211 netlink interface. The 'dev wlan0 scan' subcommand triggers a scan on the named device and reports each discovered BSS with its SSID, frequency or channel, and signal strength in dBm. Triggering a new scan normally requires root privileges.
Why the other options are wrong- Biw dev wlan0 link is incorrect because link shows information about the currently associated AP only and does not scan for others.
- Ciw dev wlan0 info is incorrect because info prints the device's current configuration (type, channel, txpower) rather than performing a scan.
- Diw phy phy0 channels is incorrect because that lists the channels the hardware supports, not the access points currently in range.
-
An administrator must quantify the memory footprint of a single process (PID 7700) for a capacity report. Which TWO commands give an accurate per-process view of its resident memory rather than just system-wide totals? (Choose TWO)
- Apmap -x 7700 and read the total RSS lineCorrect
- Bps -o pid,rss,vsz -p 7700Correct
- Ctop -p 7700 and read the VIRT column
- Dcat /proc/7700/statm and read the first field
✓ Correct answer: A, BBoth 'pmap -x' and 'ps -o rss' read per-process accounting from /proc/PID and report that single task's resident memory. 'pmap -x 7700' enumerates every mapping and prints a total RSS and dirty figure for the process, while 'ps -o pid,rss,vsz -p 7700' prints the resident set size and virtual size directly. Together they let an administrator attribute memory to one specific process for a capacity report. They are the standard per-process memory tools alongside reading /proc/7700/status (VmRSS).
Why the other options are wrong- CVIRT is the virtual memory size, including mapped but non-resident pages, so it overstates resident memory.
- DThe first statm field is the total program size (as VmSize), not the resident size, which is the second field.
Who this LPIC-2 practice exam is for
This practice set is for anyone preparing for the LPIC-2: Linux Engineer exam at the intermediate level - from first-time candidates building a foundation to experienced Linux practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.
How to use this LPIC-2 practice exam
- Start with the free sample questions above to gauge your current baseline.
- Read the full explanation on every question, including why each wrong option is wrong.
- Track your weak domains and focus your study where you are losing the most marks.
- Once you are scoring consistently well, take a timed, full-length mock exam.
- Use your readiness score to decide when you are ready to book the real LPIC-2 exam.
Related Linux resources
- LPIC-2 study guideKey concepts
- Linux practice examsAll Linux
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- Hands-on lpic-2 labsLearn
- Hands-on lpic-1 labsLearn
- LPIC-2 command cheat sheetCheat sheet
- LPIC-1 command cheat sheetCheat sheet
- How these questions are written and reviewedMethodology
- Report a problem with a questionCorrections
- Red Hat Certified Ansible (EX294-style) practice examRelated
- Red Hat Certified System Administrator (RHCSA, EX200-style) practice examRelated
- CompTIA Linux+ (XK0-006) practice examRelated
LPIC-2 practice exam FAQ
How many questions are in the LPIC-2 practice exam on CertGrid?
CertGrid has 817 practice questions for LPIC-2: Linux Engineer, covering 12 exam domains. The real LPIC-2 exam is 60 qs per exam in 90 min per exam. CertGrid's timed mock is a fixed 60 questions.
What is the passing score for LPIC-2?
LPIC-2 is earned by passing two exams, 201 and 202; LPI reports each result as a scaled score (roughly 200-800) rather than a fixed pass mark. You have about 90 min per exam to complete it. CertGrid tracks your readiness against the exam objectives so you know where to focus.
Are these official LPIC-2 exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the LPIC-2: Linux Engineer exam.
Is there a free LPIC-2 practice test?
Yes. You can take a free LPIC-2: Linux Engineer practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 817-question bank, timed mock exams and full-bank domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Linux Professional Institute. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.