LPIC-2 Exam 201-450, Part 1 of 2: Version 4.5 Study Guide
LPIC-2 Exam 201-450 validates advanced Linux administration across capacity planning, kernel work, system startup, filesystems, storage, networking, and maintenance. It is intended for Linux professionals who need to administer small to medium-sized mixed networks, not simply recall isolated commands. This guide helps you decide whether your current LPIC-1 foundation is sufficient, which Exam 201 domains deserve the most study time, how to build a practical lab, and when your preparation is strong enough to schedule the first of the two exams required for LPIC-2.
What does LPIC-2 Exam 201-450 validate?
Exam 201-450 tests the administration skills behind a functioning Linux site: measuring resource use, managing kernels, recovering systems, maintaining filesystems, administering storage, configuring networks, and carrying out routine maintenance. The official Exam 201 objectives describe these skills as part of the ability to administer small to medium-sized mixed networks.
The exam is Part 1 of 2 for LPIC-2. Passing Exam 201 alone does not grant the certification. LPI requires passing both Exam 201 and Exam 202, and the candidate must hold an active LPIC-1 certification to receive LPIC-2. The two exams may be taken in any order, but all certification requirements must be met.
The version matters. LPI identifies LPIC-2 version 4.5 with exam codes 201-450 and 202-450. The LPI Wiki also contains a version 5.0 draft, while the version 4.5 objectives remain available. If your study material follows a different blueprint, compare every chapter against the version 4.5 objective page before relying on it.
Who should take Exam 201 first?
Exam 201 is a sensible first step for a candidate whose stronger experience is operating Linux systems rather than deploying network-facing services. Its coverage moves from diagnosis and kernel behavior through boot, filesystems, storage, interfaces, and backups, so it rewards an administrator who can trace a problem across several system layers.
It is also appropriate for a working Linux administrator who wants to formalize practical knowledge. The certification target is broader than one distribution or one job title: the objectives cover common Linux administration concepts, command-line utilities, configuration files, and service-management approaches.
What are the Exam 201 domains and weights?
Use the official weights to allocate study time, but do not treat them as a pass guarantee. LPI states that objective weights indicate relative importance and that objectives with higher weights are covered with more questions. A high-weight area should receive more practice, while a low-weight area still needs deliberate coverage because the blueprint includes it.
The version 4.5 Exam 201 blueprint contains seven topics. The following list preserves the official domain names and objective weights:
Capacity Planning includes “Measure and Troubleshoot Resource Usage” at weight 6 and “Predict Future Resource Needs” at weight 2. Linux Kernel includes “Kernel components” at weight 2, “Compiling a Linux kernel” at weight 3, and “Kernel runtime management and troubleshooting” at weight 4. System Startup includes “Customizing system startup” at weight 3, “System recovery” at weight 4, and “Alternate Bootloaders” at weight 2.
Filesystem and Devices includes “Operating the Linux filesystem” at weight 4, “Maintaining a Linux filesystem” at weight 3, and “Creating and configuring filesystem options” at weight 2. Advanced Storage Device Administration includes “Configuring RAID” at weight 3, “Adjusting Storage Device Access” at weight 2, and “Logical Volume Manager” at weight 3.
Networking Configuration includes “Basic networking configuration” at weight 3, “Advanced Network Configuration” at weight 4, and “Troubleshooting network issues” at weight 4. System Maintenance includes “Make and install programs from source” at weight 2, “Backup operations” at weight 3, and “Notify users on system-related issues” at weight 1.
A practical priority follows from the labels and weights: begin with resource troubleshooting, then combine kernel runtime work, recovery, filesystem operations, advanced networking, and storage. After that, close the smaller gaps in source installation, notifications, and lower-weight objectives. This is a recommendation based on the blueprint, not an official passing threshold.
How should weight influence a study plan?
Create a table with one row per objective and three columns: explain, perform, and troubleshoot. Give the largest weekly blocks to Capacity Planning’s “Measure and Troubleshoot Resource Usage” at weight 6, then to Linux Kernel’s runtime management and troubleshooting at weight 4, System Startup’s recovery at weight 4, Filesystem and Devices’ operating objective at weight 4, and Networking Configuration’s advanced and troubleshooting objectives at weight 4.
Do not spend all your time on the largest numbers. A candidate who can run a monitoring command but cannot explain what a changed value means still has a gap. Use weights to choose the order of practice, then use the objective wording to decide what evidence of readiness looks like.
What changed in version 4.5?
Version 4.5 expanded or modernized several areas compared with version 4.0. For Exam 201, the change summary identifies added tools such as iotop, htop, ss, and iptraf in resource usage; Linux 4.x and xz coverage in kernel work; DKMS in kernel compilation; UEFI and NVMe booting in recovery; systemd mount units; Btrfs awareness; SSD, NVMe, and SAN awareness; iw and additional network troubleshooting tools; and xz in source installation.
The update also increased systemd coverage and introduced or clarified technologies that are easy to miss when using an older book. The summary specifically notes systemd, journaling, filesystem mounting, IPv6 and TLS where applicable, DKMS, Btrfs, UEFI, NVMe, xz, iotop, htop, ss, and other additions across the LPIC-2 exams.
This does not mean every newer Linux feature belongs in a version 4.5 study plan. It means you should map your resources to the version 4.5 list. In particular, do not substitute the version 5.0 draft for the requested blueprint: the draft reorganizes Exam 201 around different topics, including Ansible and resource management.
Which older topics require caution?
The version 4.5 summary says detailed knowledge of lilo was removed from the update and alternate-bootloader coverage was adjusted toward UEFI booting and awareness of systemd-boot and U-Boot. Study the version 4.5 objective language rather than assuming that an older preparation book gives equal emphasis to every bootloader.
The summary also records that awareness-level coverage was reduced for some tools and that several technologies were updated, including Linux 4.x, Apache 2.4, Samba 4, and OpenLDAP directory-based configuration. Those examples belong to the overall LPIC-2 update; for Exam 201, concentrate on the specific additions and wording attached to its seven topics.
How should you build an Exam 201 lab?
Use an isolated Linux lab with at least one system you can reboot, inspect, reconfigure, and deliberately break. The goal is not to reproduce a production site. It is to make each objective observable: generate resource pressure, inspect kernel state, alter boot configuration safely, mount filesystems, create temporary storage layouts, configure interfaces, capture traffic, compile a small source project, and restore selected data.
Keep the lab disposable. Use virtual machines or another environment where snapshots and console access are available, and record the distribution and commands used for each exercise. The objectives are distribution-independent in scope, but paths, package names, service defaults, and configuration locations can differ. Treat your lab output as evidence of understanding, not as a script to memorize.
Maintain a change log with four entries for each exercise: initial state, change made, verification command, and recovery step. This habit is especially useful for kernel, startup, filesystem, RAID, LVM, and networking tasks, where the important skill is often identifying the correct diagnostic sequence rather than typing one isolated command.
What should the lab exercises prove?
For Capacity Planning, collect observations with tools named in the objectives, including iostat, iotop, vmstat, ss, iptraf, pstree, ps, lsof, top, htop, uptime, and sar. Explain whether a symptom indicates CPU pressure, memory pressure, blocked processes, disk I/O, socket activity, or network traffic. Then write a short recommendation about what additional measurement would confirm your diagnosis.
For kernel work, inspect the running kernel and modules, compare module information with the active hardware or feature, and practice the relationships among /usr/src/linux/.config, /lib/modules/kernel-version/, depmod, DKMS, initramfs tools, and module-loading utilities. Do not make an experimental kernel your only boot option.
For startup and recovery, trace the path from firmware through bootloader, kernel, initramfs, and service initialization. Practice using systemd and the relevant SysV concepts in the version 4.5 objectives. Make a recovery checklist that starts with console access and ends with verification after reboot.
For storage, use disposable virtual disks to create and inspect software RAID and LVM layouts. Work through a failed-device scenario in the lab, inspect /proc/mdstat, and verify mounts and device mappings. Do not use valuable disks or a real production array for learning exercises.
For networking, configure a local wired or wireless connection where possible, inspect routes and addresses, test name resolution separately from reachability, and capture traffic only in the isolated environment. Include both IPv4 and the version 4.5 IPv6-related awareness noted in the objectives.
How do you study Capacity Planning and kernel topics?
Start with diagnosis rather than memorizing tool descriptions. Exam 201 expects you to measure resource use, identify problems, and think about future needs. Kernel objectives then ask you to understand components, compilation, modules, and runtime troubleshooting. The common thread is evidence: observe the system, form a hypothesis, select a focused command, and verify the result.
For 200.1, build a symptom-to-evidence matrix. A high load value is not automatically a CPU problem; blocked processes, storage latency, memory pressure, and network activity require different evidence. Practice reading command output in context and explaining what you would measure next. The objective includes tools such as iostat, iotop, vmstat, netstat, ss, lsof, top, htop, uptime, and sar.
For 200.2, turn observations into a basic capacity recommendation. Record a baseline, identify a trend, describe the resource approaching exhaustion, and state what measurement would justify an upgrade or configuration change. The objective includes awareness of monitoring solutions such as Icinga2, Nagios, MRTG, and Cacti; do not confuse awareness with full product administration.
For 201.1, learn the relationship between the kernel, hardware drivers, system resources, and loadable components. For 201.2, rehearse the kernel source workflow and the purpose of configuration and build targets, including make, configuration targets, modules, modules_install, and compression tools. For 201.3, practice querying the running kernel and modules, checking logs, identifying a module issue, and understanding the role of DKMS and initramfs generation.
A common mistake is treating kernel compilation as a sequence of commands divorced from boot requirements. Before changing anything, know which kernel is running, where its modules are installed, how the initramfs is produced, and how the bootloader will select the result. Your lab record should show how you would return to a known working kernel.
What is a useful kernel troubleshooting sequence?
Begin with the symptom and current state: identify the running kernel, inspect relevant messages, query loaded modules, and check whether the expected device or feature is present. Then compare configuration, module availability, dependencies, and initramfs contents. Make one controlled change, reload or reboot only when appropriate, and verify the result.
Avoid jumping directly to recompilation. A missing feature may be a loadable module, a dependency problem, a stale initramfs, a DKMS build issue, or a configuration choice. The objective tests the distinctions among these possibilities, so explaining why a step is needed is more valuable than repeating a build command.
How should you prepare for system startup and recovery?
Practice recovery as a decision tree: determine whether the failure occurs before the kernel, during initramfs handling, during the init system, or when a service starts. Version 4.5 covers startup customization, recovery, and alternate bootloaders, including UEFI and NVMe booting. Your preparation should therefore include both boot architecture and safe recovery actions.
Review the contents and roles of /boot/, /boot/grub/, and /boot/efi/, the EFI System Partition, GRUB, grub-install, efibootmgr, initrd, initramfs, the Master Boot Record, and systemctl. Understand the handoff from firmware to bootloader, from bootloader to kernel, and from kernel initialization to daemon or service startup.
For systemd, distinguish unit locations and the effect of an override or drop-in from the vendor-provided unit. Practice inspecting the active configuration, identifying dependencies, checking failed units, reading the journal, and reverting a local change. The version 4.5 summary specifically identifies increased systemd coverage, journaling, and filesystem mounting.
For recovery exercises, deliberately create a harmless service or mount failure in a disposable machine. Record how you enter recovery mode, obtain enough access to repair the problem, validate configuration before rebooting, and confirm that the repaired system starts normally. Keep a second access path available; locking yourself out is not a useful test of knowledge.
A frequent pitfall is confusing a bootloader repair with a kernel repair. If the firmware cannot find a boot entry, investigate UEFI and bootloader placement. If the bootloader starts but the kernel cannot mount the root filesystem, investigate the kernel, initramfs, storage driver, or filesystem. If the system reaches the init system but a unit fails, investigate the unit and its dependencies.
What bootloader coverage is appropriate for version 4.5?
Focus on GRUB version 2 and GRUB Legacy as the bootloaders of interest in the version 4.5 objective, together with the updated UEFI booting coverage. The change summary says lilo was removed from detailed coverage and that awareness of systemd-boot and U-Boot was added. This is a reason to read the objective wording carefully, not to ignore boot concepts.
How do you master filesystems and storage without memorizing tables?
Learn storage as a layered system: block device, partition or virtual device, filesystem, mount point, persistent configuration, and application use. Exam 201 connects filesystem operation and maintenance with RAID, device access, and LVM. Build and dismantle small lab layouts until you can identify which layer is failing and choose a tool that belongs to that layer.
For Filesystem and Devices, practice navigating the standard Linux filesystem and explain the purpose of important administrative locations. For maintenance, use filesystem-specific tools appropriately for ext2, ext3, ext4, and XFS, and understand the stated awareness of Btrfs. For filesystem options, rehearse /etc/fstab, UUID-based identification, mount and umount, swap files or partitions, and systemd mount or automount concepts.
The version 4.5 objectives list tools such as fsck and fsck.*, mkfs and mkfs.*, dumpe2fs, xfsdump, xfsrestore, debugfs, tune2fs, mkswap, xfs_info, xfs_check, xfs_repair, smartd, and smartctl. Learn what question each tool answers and what risk it carries. Never run repair tools against a mounted or valuable filesystem merely to gain practice.
For RAID, understand the purpose and trade-offs of RAID 0, 1, and 5, then use mdadm and inspect mdadm.conf and /proc/mdstat in the lab. The official objectives explicitly include configuring RAID 0, 1, and 5. Practice identifying an array state, locating the affected member, and confirming recovery, but do not mistake redundancy for backup.
For adjusting storage device access, review the tools and concepts named by the objective, including hdparm, sdparm, tune2fs, sysctl, DMA, interrupts, IDE, ATAPI, SATA, and iSCSI. Version 4.5 also adds SSD and NVMe configuration and awareness of SAN. Treat WWID, WWN, and LUN as identifiers or storage concepts to explain, not labels to recite without context.
For LVM, work through the complete lifecycle: physical volumes, volume groups, logical volumes, device mappings, mounting, resizing, renaming, removing, snapshots, and activation. Keep a diagram of the relationship between each layer. A common error is attempting a filesystem operation when the required change belongs to the logical volume, or resizing a logical volume without considering the filesystem.
What storage checklist should you use after every change?
First identify the device and current topology. Next check whether the intended RAID, volume, filesystem, or mount state is visible. Then validate persistence, capacity, permissions, and application access. Finally document how to reverse the change. For LVM snapshots and filesystem resizing, include a specific consistency check rather than assuming that a successful command means the data is safe.
Keep RAID recovery, LVM snapshots, and backups conceptually separate. RAID can help maintain availability after a disk failure; an LVM snapshot can provide a point-in-time copy for a task; a backup is a separate recoverable copy. The objectives cover these technologies, but none should be treated as a substitute for the others.
How should you study Networking Configuration?
Use a layered troubleshooting method: link and interface, address, route, local filtering, transport, and application. Exam 201 covers basic and advanced network configuration plus troubleshooting, so you need more than command syntax. You should be able to identify which layer is broken, select a diagnostic tool, and explain why a successful test does or does not prove the service works.
For basic networking, practice configuring a device for local wired or wireless and wide-area connectivity. Review interface and routing utilities named in the objectives, including ip, ifconfig, route, arp, iw, iwconfig, and iwlist. Version 4.5 added iw to the basic network coverage, so older material that focuses only on legacy wireless tools is incomplete.
For advanced networking, configure addresses, routes, and basic wireless access in a lab. Review network authentication schemes at the level required by the objective, and understand how interface state, address selection, route choice, and name-service configuration interact. The objective includes utilities such as ip, ifconfig, route, arp, iw, iwconfig, and iwlist.
For troubleshooting, use a repeatable sequence. Confirm the interface is present and up; inspect addresses; inspect the route; test the local stack; test the next hop; test a remote address; test name resolution; then inspect transport and application behavior. The objective lists ss, netstat, lsof, ping, ping6, nc, tcpdump, and nmap among the relevant tools.
The version 4.5 change summary adds or expands systemd coverage and identifies ip, ss, ping6, traceroute6, and mtr for network troubleshooting. It also records IPv6 additions elsewhere in the update. Do not make an IPv4-only lab your entire preparation; at minimum, be able to read IPv6 address and route information and distinguish reachability from name-resolution failure.
A common mistake is testing only with ping. Ping can show that an address responds, but it does not prove that a particular port is listening, that a route is correct in both directions, or that an application is healthy. Pair reachability tests with socket inspection, packet capture, and service-level checks.
How can you turn networking commands into diagnosis?
For each command, write the question before you run it. Use ip to ask about links, addresses, and routes; ss or netstat to ask about sockets; tcpdump to ask what packets are actually moving; nc or nmap to investigate reachable ports in the lab; and ping or ping6 to test selected network paths. This prevents command collecting without interpretation.
Create failures one at a time: remove a route, use an incorrect address, stop a listener, introduce a filtering rule, or point name resolution at the wrong place. Record the first observable symptom and the shortest sequence that isolates it. Restore the configuration after each exercise and confirm that the original path works.
What maintenance tasks belong in your final revision?
System Maintenance is smaller than several other Exam 201 domains, but it contains practical administrator work: building and installing programs from source, backing up important data, and notifying users about system-related issues. Treat it as a final integration block after you understand storage, filesystems, startup, and permissions.
For source installation, rehearse the flow from source archive to inspection, configuration, compilation, installation, and verification. Review /usr/src/, /usr/local/src/, gunzip, gzip, bzip2, xz, tar, configure, make, uname, install, and patch. The objective includes awareness of build targets and compression tools; learn to distinguish source preparation from package management and record where installed files go.
For backups, use the utilities and devices named by the objective, including dd, tar, tape-device paths, mt, and rsync. Define what is being protected, where the copy is stored, and how it will be restored before running the backup. Test a small restoration. A backup command that completes without an intentionally verified restore is only a partial exercise.
For user notifications, understand the purpose of /etc/issue, /etc/issue.net, /etc/motd, wall, shutdown, and systemctl in the context of planned or urgent maintenance. The weight for “Notify users on system-related issues” is 1, but the operational judgment is still worth learning: communicate the problem, impact, expected action, and return to service without exposing unnecessary information.
What is the most useful backup exercise?
Choose a small directory containing configuration and test data, create a backup using one suitable method, remove or alter selected files, and restore them to a separate location first. Compare ownership, permissions, timestamps, symbolic links, and contents. Then write down the restore command and the limitation of the backup method you used.
Do not assume that copying a live system directory is always consistent. For exam preparation, focus on tool purpose, archive and device handling, synchronization behavior, and restoration reasoning. In a real environment, define application-consistency requirements separately from the mechanics of the command.
How should the study roadmap be sequenced?
A four-stage roadmap works well: establish the blueprint, build core diagnostic skills, integrate recovery and storage, then test weak areas under time pressure. The sequence follows dependencies rather than simply following topic numbers. For example, filesystem and storage exercises are more useful after you understand devices and boot recovery, while network troubleshooting becomes clearer when you separate measurement from configuration.
Stage 1: map the version 4.5 objectives. Mark every objective as new, familiar, or demonstrable. Confirm that your LPIC-1 certification is active if you intend to claim LPIC-2 after both exams. Download or save the official version 4.5 objective list and use its partial lists of files, terms, and utilities to build your study checklist.
Stage 2: study Capacity Planning, Linux Kernel, and Networking Configuration together as diagnostic disciplines. For each session, spend part of the time reading the objective, part performing a lab task, and part explaining the result in writing. Keep a mistake log that records the symptom, mistaken assumption, corrective evidence, and command or file that resolved it.
Stage 3: work through System Startup, Filesystem and Devices, and Advanced Storage Device Administration. Take snapshots before risky exercises, maintain a topology diagram for disks and volumes, and practice returning a broken virtual machine to a bootable state. Finish each lab by checking persistence after reboot where persistence is part of the task.
Stage 4: complete System Maintenance and conduct mixed scenarios. A useful scenario might begin with a resource symptom, continue through a storage or filesystem check, require a network test, and finish with a backup or maintenance notice. The point is to decide what to inspect first, not to execute every command you know.
In the final revision, use the official weights to revisit the largest gaps, but also review every weight 1 and weight 2 objective. Make a one-page map of commands, files, concepts, and verification steps. Do not turn it into a list of unsupported shortcuts or leaked questions; memorization of unauthorized material does not establish the skills the objectives describe.
How do you know you are ready to schedule?
You are ready to consider scheduling when you can explain every version 4.5 objective in plain language, perform the central lab task without copying a recipe, diagnose a deliberately introduced failure, and restore the system safely. You should also be able to distinguish an official requirement from a personal study target: LPI publishes the certification requirements and blueprint; your readiness checklist is your own preparation decision.
Before scheduling, verify the exam code and blueprint version on LPI’s official pages. Check the delivery option and language you intend to use, then confirm current appointment requirements directly with the relevant provider. Do not rely on an old guide for availability, policies, or platform conditions.
What are the delivery details for Exam 201-450?
LPI’s overview lists Exam 201-450 as a 90-minute exam containing 60 multiple-choice and fill-in-the-blank questions. The same overview lists LPIC-2 test-center languages as English, German, Japanese, and Brazilian Portuguese. Treat these as official exam details for the listed version, while confirming the current appointment information before purchase.
LPI also offers LPIC-2 Exams 201 and 202 through Pearson VUE’s OnVUE online-testing system. LPI’s online-testing information says candidates need a quiet, private location, a reliable computer with a camera, and a stable Internet connection; it also states that Windows and MacOS are supported. The page says LPIC-2 online exams are available in English, while the LPIC-2 overview lists English and Japanese for online OnVUE delivery. Because the pages present different language information, verify the language shown for your intended appointment before booking.
The online-testing page says online proctoring uses a verified Pearson VUE proctor and directs candidates to Pearson VUE’s system requirements, policies, and procedures. It also states that prices and lengths remain the same on OnVUE as in test centers, but this guide does not reproduce a price because LPI directs candidates to country-specific pricing.
Delivery is a scheduling decision, not a study shortcut. If you choose OnVUE, check the equipment, operating-system support, private-room requirement, camera, and connection well before the appointment. If those conditions are inconvenient, review the test-center option and its available language information on the official LPI pages.
What should you verify immediately before booking?
Verify four items on the official LPI and Pearson VUE information: the exam code 201-450, the version 4.5 objective set, the language and delivery method, and the current technical or appointment requirements. Then confirm that your LPIC-1 status satisfies the LPIC-2 certification prerequisite. These checks prevent preparing for the wrong blueprint or discovering a delivery constraint too late.
What should you do next?
Open the official version 4.5 objectives and turn Topics 200 through 206 into a checklist. Set up a disposable Linux lab, begin with resource measurement, and keep a dated error log. Next, choose a realistic target window only after you have verified the current delivery details and can demonstrate the high-weight troubleshooting objectives rather than merely recognize their command names.
After Exam 201, continue to Exam 202 preparation instead of assuming that Part 1 represents the whole certification. LPIC-2 requires both exams, and Exam 202 covers a different group of network-service and security domains. Keeping the two blueprints separate will help you measure progress accurately and avoid mixing version 4.5 objectives with the version 5.0 draft.
Conclusion
Exam 201-450 is best approached as an administration and diagnosis exam: measure before changing, understand the layer you are working on, verify persistence, and keep a recovery path. Use the version 4.5 blueprint as the authority, give additional practice to its higher-weight objectives, and use a disposable lab to turn commands into repeatable decisions. Confirm the current exam code, language, delivery requirements, and prerequisite status through LPI before scheduling the first part of the LPIC-2 path.
