201-450
LPIC-2 Exam 201, Part 1 of 2, version 4.5
LPIC-2 Exam 201, Part 1 of 2: Version 4.5 Study Guide
LPIC-2 Exam 201 validates advanced Linux administration skills across capacity planning, the kernel, startup, filesystems, storage, networking, and system maintenance. It is intended for administrators working toward the ability to manage small-to-medium-sized mixed networks. This guide helps you decide whether your preparation should focus on rebuilding fundamentals, practicing operational troubleshooting, or scheduling Exam 201-450 after you have covered the version 4.5 objectives and confirmed the LPIC-2 certification requirements.
What Exam 201-450 is designed to validate
Exam 201 is the first of the two exams required for LPIC-2 certification. Its scope is practical administration rather than a single distribution: the version 4.5 objectives cover how a Linux administrator measures resources, manages kernels and boot, maintains filesystems and storage, configures networks, and performs routine system maintenance.
LPI describes LPIC-2 as validating the ability to administer small to medium-sized mixed networks. The broader certification also expects advanced system administration, block storage and filesystem management, networking, authentication, security, and fundamental network services. Exam 201 supplies the operating-system and infrastructure side of that role; Exam 202 covers the service-heavy portion.
The objective page says that objective weights show relative importance and that higher-weighted objectives receive more questions. Treat the weights as a study-allocation signal, not as a prediction of the exact question mix. You still need working familiarity with every listed objective, including weight 1 material.
Who should take this exam first
Choose Exam 201 as your immediate target if you already handle Linux command-line administration and want to test deeper operational judgment. It is a sensible first LPIC-2 exam for a candidate whose stronger areas are troubleshooting, storage, boot, networking, and system maintenance rather than DNS, mail, web, or file-server configuration.
LPIC-2 certification requires passing both Exam 201 and Exam 202, and the candidate must hold an active LPIC-1 certification to receive the certification. LPI states that the exams may be taken in either order, so your choice can follow your experience and preparation rather than a required sequence.
Which version should guide your study
Use the version 4.5 objectives and the 201-450 exam code when that is the exam you intend to take. LPI’s overview identifies version 4.5 as the LPIC-2 version and lists Exam 201-450 and Exam 202-450. The LPI Wiki also contains a version 5.0 draft, so do not mix its redesigned topics into a version 4.5 study checklist.
The version 4.0-to-4.5 summary records the main changes: more systemd, IPv6, TLS, Btrfs, UEFI, NVMe, xz, iotop, htop, ss, and related tools, while detailed LILO knowledge was removed. This makes the summary useful for checking older books, but the version 4.5 objective list remains the controlling study outline for this guide.
How to read the Exam 201 blueprint
The seven Exam 201 domains form a progression from observation to intervention: measure a system, understand its kernel and startup path, manage its filesystems and devices, configure connectivity, and maintain software and data. Build your study plan around that progression so that commands are connected to diagnosis and recovery rather than memorized as isolated entries.
Capacity Planning: prioritize diagnosis before prediction
Topic 200 begins with 200.1 Measure and Troubleshoot Resource Usage (weight: 6), the heaviest Exam 201 objective. It covers measuring hardware resources and network bandwidth and identifying and troubleshooting resource problems. Topic 200 also includes 200.2 Predict Future Resource Needs (weight: 2), which emphasizes monitoring usage to anticipate growth and resource exhaustion.
For 200.1, practice interpreting evidence from tools named in the objectives, including iostat, iotop, vmstat, ss, netstat, lsof, ps, top, htop, uptime, and sar. Do not merely record what each command displays. For each symptom, write down the resource involved, the observation that supports it, and the next command that would narrow the cause.
For 200.2, focus on trends and decisions: what would you monitor, how would you distinguish a short spike from sustained pressure, and what evidence would support additional capacity? The objective includes awareness of monitoring solutions such as Icinga2, Nagios, collectd, MRTG, and Cacti. Awareness does not justify spending most of your lab time installing every platform.
Linux Kernel: connect components, builds, and runtime behavior
Topic 201 covers 201.1 Kernel components (weight: 2), 201.2 Compiling a Linux kernel (weight: 3), and 201.3 Kernel runtime management and troubleshooting (weight: 4). The domain tests the relationship between kernel configuration, modules, boot artifacts, and the running system.
Create a kernel reference sheet that distinguishes the source tree, configuration file, installed modules, module dependency information, and initramfs or initrd. The objectives name /usr/src/linux/, /usr/src/linux/.config, /lib/modules/kernel-version/, depmod, DKMS, mkinitrd, mkinitramfs, and awareness of dracut. Practice identifying which artifact must change when a driver is missing at boot versus when a module must be loaded after startup.
For compilation, rehearse the purpose of configuration targets such as config, menuconfig, xconfig, oldconfig, and mrproper, together with build and installation targets such as bzImage, modules, and modules_install. You do not need to turn every lab into a production kernel build. You do need to understand the sequence, the role of the configuration, and how to verify the resulting kernel and modules.
For runtime troubleshooting, use command-line utilities to query the running kernel and loadable modules. Build scenarios around a missing module, an incorrect module option, a dependency problem, and a kernel version mismatch. Record both the query command and the corrective action; knowing only the loading command leaves a major troubleshooting gap.
System Startup: learn the boot handoff and recovery path
Topic 202 covers 202.1 Customizing system startup (weight: 3), 202.2 System recovery (weight: 4), and 202.3 Alternate Bootloaders (weight: 2). The objectives cover systemd alongside SysV init, recovery mode, UEFI, NVMe booting, GRUB 2, and GRUB Legacy.
Draw the startup path from firmware through the bootloader, kernel, initramfs, and service initialization. Then annotate where you would look when the machine fails before the root filesystem is mounted, when a service fails after boot, and when a system reaches an unusable target. The version 4.5 changes specifically added systemd coverage and UEFI and NVMe booting.
Practice systemctl operations in a disposable virtual machine: inspect units, identify dependencies, compare enabled and active states, and use logs to investigate a failed unit. Keep SysV concepts visible as well: /etc/inittab, /etc/init.d/, /etc/rc.d/, chkconfig, update-rc.d, init, and telinit are named in the objectives. The aim is to recognize both administrative models and their relationship.
For recovery, practice entering a maintenance environment without treating it as a shortcut around diagnosis. Know how filesystem mounting, fsck, initramfs, GRUB, and systemctl fit into recovery decisions. For alternate bootloaders, learn the major features and install locations that distinguish GRUB 2, GRUB Legacy, and the surrounding BIOS or UEFI process.
Filesystem and Devices: separate operation from maintenance
Topic 203 has three distinct jobs: 203.1 Operating the Linux filesystem (weight: 4), 203.2 Maintaining a Linux filesystem (weight: 3), and 203.3 Creating and configuring filesystem options (weight: 2). The first concerns navigation and configuration, the second concerns health and repair, and the third concerns automounting and encryption-related options.
Build a filesystem lab that uses /etc/fstab, UUIDs, blkid, mount, umount, swapon, and swapoff. Compare /etc/mtab with /proc/mounts, and include a systemd mount unit so that a persistent mount is not treated as an fstab-only problem. Always test a changed mount configuration safely before rebooting; a syntax error or wrong device identifier can turn a routine exercise into a recovery exercise.
For maintenance, practice selecting the appropriate filesystem tool rather than applying fsck generically. The version 4.5 objectives include ext2, ext3, ext4, XFS, and awareness of Btrfs, with tools such as dumpe2fs, debugfs, tune2fs, xfsdump, xfsrestore, xfs_info, xfs_check, and xfs_repair. Learn what information each tool provides and when a repair operation requires the filesystem to be unmounted.
For 203.3, configure an AutoFS map using /etc/auto.master and an /etc/auto.* file, then examine systemd automount units. The objective also names UDF and ISO9660 tools, CD-ROM extensions such as Joliet, Rock Ridge, and El Torito, and basic dm-crypt or LUKS knowledge. Treat encryption as a lifecycle topic: identify the device, understand the mapping, and know what persistent configuration is required.
Advanced Storage: rehearse state changes, not just definitions
Topic 204 contains 204.1 Configuring RAID (weight: 3), 204.2 Adjusting Storage Device Access (weight: 2), and 204.3 Logical Volume Manager (weight: 3). These objectives reward a controlled understanding of storage layers, status inspection, resizing decisions, and recovery consequences.
Use loop devices or disposable virtual disks for RAID practice. The version 4.5 objective includes software RAID 0, 1, and 5, along with recovery of a failed RAID device and replacement of a failed disk. Practice reading /proc/mdstat, understanding mdadm configuration, and distinguishing a degraded array from a healthy one. Never use a valuable disk or a production array for an experiment.
For device access, study the named tools and concepts together: hdparm, sdparm, tune2fs, sysctl, DMA, interrupts, IDE or SATA devices, and iSCSI tools such as iscsiadm, scsi_id, and iscsid. The objective also names WWID, WWN, and LUN numbers. The practical question is which identifier or layer is being adjusted, not simply which command exists.
For LVM, work through the complete lifecycle of physical volumes, volume groups, and logical volumes using the pv*, vg*, and lv* tools. Include creation, removal, resizing, renaming, activation, mounting through /dev/mapper/, and snapshots. Keep a written map of the underlying device, volume group, logical volume, filesystem, and mount point; most avoidable mistakes come from confusing these layers.
Networking Configuration: make troubleshooting systematic
Topic 205 includes 205.1 Basic networking configuration (weight: 3), 205.2 Advanced Network Configuration (weight: 4), and 205.3 Troubleshooting network issues (weight: 4). The domain expects configuration and diagnosis across wired and wireless interfaces, routes, authentication, and TCP/IP traffic.
Start with a repeatable path: inspect the interface and address, check the route, verify name resolution separately, test reachability, inspect listening sockets, and capture traffic only when earlier evidence leaves an unanswered question. The version 4.5 objectives name ip, ifconfig, route, arp, ss, netstat, lsof, ping, ping6, nc, tcpdump, and nmap. Practice explaining what each result rules in or rules out.
For basic configuration, configure a local wired connection and a wireless connection in a lab. The objective names ip, ifconfig, route, arp, iw, iwconfig, and iwlist. Do not assume that a successful association proves usable network service: address assignment, routing, DNS, and firewall behavior remain separate checks.
Advanced network configuration includes interface manipulation and basic wireless access, as well as network authentication schemes. Build comparison notes for legacy tools and iproute2 tools, and include IPv6 tests rather than studying IPv4 alone. The version 4.5 update added IPv6-related coverage, including ping6 and other troubleshooting commands.
For 205.3, deliberately introduce faults: an incorrect default route, a duplicate or missing address, a wrong resolver, a blocked port, and a service listening only on the loopback address. Capture the exact observation that identifies each fault. This is more useful than copying a list of commands because the exam objective is to identify and correct common setup issues.
System Maintenance: finish with repeatable operational work
Topic 206 covers 206.1 Make and install programs from source (weight: 2), 206.2 Backup operations (weight: 3), and 206.3 Notify users on system-related issues (weight: 1). The domain is smaller than networking or capacity planning, but it tests whether you can complete changes safely and communicate their effect.
For source installation, practice the sequence from source archive to configuration, compilation, installation, and verification. The objectives name /usr/src/, /usr/local/src/, gunzip, gzip, bzip2, xz, tar, configure, make, uname, install, and patch. Keep a record of where files were installed and how you would remove or update them; a successful build without change tracking is difficult to maintain.
For backups, compare what is being protected, how metadata is preserved, how the destination is selected, and how restoration would be verified. The objective names /bin/sh, dd, tar, /dev/st*, /dev/nst*, mt, and rsync, and the version 4.5 summary notes awareness of Bareos. Perform at least one restore into a separate location. A backup command is not evidence of recoverability until the restored files and permissions are checked.
For 206.3, practice communicating maintenance with /etc/issue, /etc/issue.net, /etc/motd, wall, shutdown, and systemctl. The objective has weight 1, so keep the review focused: know which mechanisms notify users and how notification fits into a controlled maintenance window.
A preparation method that matches the blueprint
Use the objective list as a skills audit, then turn each weak objective into a small lab and a troubleshooting note. Spend more time on higher-weight domains, but do not skip lower-weight objectives. A good readiness test is being able to explain the evidence, command, configuration location, and rollback or recovery path for a task.
Build a version 4.5 checklist
Create one row for every objective from 200.1 through 206.3. Add columns for concepts, files, commands, hands-on status, and unresolved questions. Mark an item complete only after you can perform or explain it without following a full recipe. Use the official objective page to resolve scope questions, especially where the version 5.0 draft uses different topic numbers or technologies.
Place the highest study priority on 200.1 Measure and Troubleshoot Resource Usage (weight: 6), 201.3 Kernel runtime management and troubleshooting (weight: 4), 202.2 System recovery (weight: 4), 203.1 Operating the Linux filesystem (weight: 4), 205.2 Advanced Network Configuration (weight: 4), and 205.3 Troubleshooting network issues (weight: 4). The labels matter: these are not interchangeable bare weights, but separate objectives with different skills.
Next, cover the weight 3 objectives, then the weight 2 and weight 1 objectives. Revisit every area after a mixed practice session because operational failures often cross domains: a boot problem can involve a filesystem, a missing module can affect networking, and a storage change can require a persistent mount update.
Use labs that produce evidence
A lab should leave behind something you can inspect: a changed unit, a degraded test array, a mount entry, a module query, a packet capture, a backup archive, or a restored file. Keep the environment disposable and record the initial state before changing it.
For each exercise, write four lines: the desired outcome, the observation that confirms it, the likely failure point, and the recovery action. This format trains the diagnostic reasoning Exam 201 needs without relying on live exam questions or memorized answer patterns.
Use distribution documentation and command help to understand behavior, but keep your final checklist tied to the version 4.5 objective wording. Package names, default paths, and service wrappers can vary by distribution; the underlying administration concepts and named tools are the safer common ground.
Avoid the most common preparation mistakes
Do not study only command syntax. Knowing that mdadm, lvcreate, systemctl, ip, or tcpdump exists is weaker than knowing what state it inspects or changes and how to verify the result.
Do not use the version 5.0 draft as a substitute for the version 4.5 blueprint. The newer draft reorganizes Exam 201 around different topics, including Ansible, resource management, and advanced SSH, while version 4.5 includes capacity planning, filesystem and devices, and the specific objectives listed above.
Do not treat objective weight as a pass guarantee or as permission to ignore weight 1 content. Higher weights indicate relative importance and more questions, but the official page does not provide a promise that mastering only high-weight objectives will be sufficient.
Do not make destructive storage, filesystem, bootloader, or kernel changes on a production system. A disposable virtual machine, snapshots, and clearly labeled test disks make it possible to practice failure and recovery without creating an avoidable outage.
Do not confuse awareness with implementation depth. If an objective says awareness of a tool or technology, learn its role, terminology, and relationship to the main task. Reserve detailed configuration practice for objectives that explicitly require configuration or administration.
A practical study roadmap
A staged roadmap is more reliable than reading every topic once. Move from measurement to core system behavior, then storage and networking, and finish with maintenance and mixed troubleshooting. Adjust the pace to your existing Linux experience; the sequence is the recommendation, not an LPI schedule.
paragraphs
Stage 1: baseline and capacity planning
Begin by taking the version 4.5 checklist without preparation. Label each item confident, familiar, or unknown. Then build a small monitoring lab and work through CPU, memory, disk I/O, process, socket, and network-bandwidth observations. Make 200.1 the anchor because Measure and Troubleshoot Resource Usage carries weight 6, while 200.2 Predict Future Resource Needs carries weight 2.
Your next action is to write a one-page diagnostic flow. Include what you check first, what evidence changes your hypothesis, and when you escalate from a local command to traffic or service inspection.
Stage 2: kernel and startup recovery
Study kernel components and build workflow before practicing runtime troubleshooting. Then create boot and recovery exercises: inspect the installed kernel, identify modules, review initramfs-related tools, examine systemd units, and recover from a deliberately broken configuration in a disposable machine.
Your next action is to explain three boot failure boundaries in your own words: before the kernel, during early userspace, and after service initialization. Add the relevant files and commands to each boundary.
Stage 3: filesystems and storage layers
Work from a block device to a filesystem and then to a persistent mount. Practice filesystem inspection and repair concepts, AutoFS, systemd automount units, RAID status and replacement, and LVM snapshots and resizing. Include UUID-based mounts and a restore or rollback step in every storage exercise.
Your next action is to draw the storage stack for your lab and annotate which command operates at each layer. If you cannot identify the layer, pause before running a command.
Stage 4: networking configuration and fault isolation
Configure wired and wireless networking, then test IPv4 and IPv6 separately. Add routes, inspect sockets, verify name resolution independently, and introduce controlled faults. The objective names both traditional utilities and newer tools, so recognize the purpose of each rather than assuming one command replaces all others in every environment.
Your next action is to create a troubleshooting table with columns for symptom, evidence, probable cause, confirming test, and correction. Keep it short enough to review repeatedly.
Stage 5: source, backup, notification, and mixed review
Finish the individual objectives with source installation, backup and restoration, and user notification. Then run mixed scenarios that combine domains, such as restoring a configuration and making its filesystem mount persist, or diagnosing a service failure after a kernel or boot change.
Your next action is to take a final pass through every checklist row and mark whether you can recall the concept, locate the relevant file, use the named tool, and verify the outcome. Schedule only after the unknown and unverified items have been addressed.
Delivery options and scheduling facts
LPI lists each LPIC-2 exam as 90 minutes with 60 multiple-choice and fill-in-the-blank questions. Exam 201 can be delivered at a Pearson VUE test center or through Pearson VUE’s OnVUE online-testing system, subject to the current availability and policies shown by LPI and Pearson VUE.
At VUE test centers, LPI lists English, German, Japanese, and Brazilian Portuguese for LPIC-2 exams. The online-testing page lists LPIC-2 online availability in English and states that the OnVUE online proctoring platform is available in English only. Confirm the current language and appointment details before purchasing or scheduling.
For OnVUE, LPI states that candidates need a quiet, private location, a reliable computer with a camera, and a stable Internet connection. The page states that Windows and MacOS are supported and directs candidates to Pearson VUE for the full system requirements, policies, and procedures. Because Linux is not listed among the currently supported operating systems on that page, do not assume that a Linux workstation can host the proctored session.
LPI’s overview lists a validity period of five years and directs candidates to its pricing information for country-specific exam costs. This guide does not reproduce a price because the official page sends candidates to location-specific pricing. Check the official scheduling and online-testing pages immediately before booking; delivery rules and availability are operational details, not study assumptions.
How to decide whether to schedule
Schedule when you can work through the official version 4.5 checklist with no major unknown domain, complete recovery-oriented labs safely, and explain why a command is appropriate. A practice score from an unofficial source is only one signal; it cannot replace coverage of the objectives and the ability to troubleshoot unfamiliar combinations.
Before booking, confirm that your LPIC-1 certification is active if LPIC-2 certification is your goal. Passing Exam 201 alone does not complete LPIC-2, because LPI requires both Exam 201 and Exam 202. Also verify that the exam code shown during registration is 201-450 if version 4.5 is your intended target.
What to do in the final review
Use the final review to reduce uncertainty, not to start a new technology stack. Revisit your error log, test the commands and configuration files you repeatedly confuse, and perform one mixed troubleshooting run without notes. Keep the official version 4.5 objective page available as the final scope reference.
Review the distinctions most likely to cause avoidable errors: runtime state versus persistent configuration, kernel modules versus initramfs contents, RAID versus LVM, address configuration versus routing, reachability versus name resolution, and backup creation versus restoration. These pairs turn broad knowledge into practical decisions.
For the exam session, plan your time around the fixed 90-minute format and 60-question structure listed by LPI. Read each question for the requested action and scope, eliminate answers that belong to another layer of the system, and return to uncertain items rather than allowing one difficult scenario to consume the session.
After this review, either schedule Exam 201-450 or record a specific gap and continue lab work. A precise delay is better than a vague feeling of unreadiness: name the objective, the missing skill, and the exercise that will close it.
Official references to keep open
Use the LPIC-2 overview for certification requirements, exam codes, format, validity, and the distinction between Exam 201 and Exam 202. Use the official Exam 201 and 202 objectives page for weights and scope, and the version 4.5 Wiki page for the detailed knowledge areas and command lists.
The version 4.0-to-4.5 summary is especially useful when a study book or older notes use previous terminology. LPI’s version 4.5 development article explains why candidates should check the updated objectives rather than relying on older preparation material.
Conclusion
Exam 201 preparation is strongest when every topic becomes an observable administrative task: measure a symptom, identify the layer involved, make a controlled change, and verify or recover the result. Confirm the version 4.5 scope, prioritize the labeled high-weight objectives, practice the full storage and boot lifecycle, and check the delivery requirements before scheduling. Once your checklist shows verified skills rather than passive familiarity, register for Exam 201-450 and plan Exam 202 as the remaining LPIC-2 requirement.