What the LFCS exam measures
The Linux Foundation describes LFCS as an online, proctored, performance-based exam completed on a Linux command line. The listed duration is two hours. The certification page emphasizes real system-administration scenarios rather than a multiple-choice knowledge check. This changes how preparation should work: reading matters, but repetition on disposable systems matters more.
The public domains are Operations Deployment 25%, Networking 25%, Storage 20%, Essential Commands 20%, and Users and Groups 10%. PrepKloud's 50 original scenarios map those percentages to 13, 12, 10, 10, and 5. That practice-set count is not a claim about the live exam. This guide also avoids a passing-score claim. Policies, instructions, permitted resources, environment details, technical requirements, and delivery behavior should be verified in official Linux Foundation resources.
The LFCS method: state, persistence, and proof
For every task, identify three layers. First is observed runtime state: what processes, sockets, mounts, routes, users, and units exist now. Second is persistent intent: which files, links, unit definitions, network profiles, repository settings, and identity policies should recreate that state. Third is functional proof: whether the requested client, service, user, or storage operation succeeds after the change.
A command returning zero is not always proof. systemctl enable does not necessarily start a service now. systemctl start does not necessarily make it survive reboot. Adding an fstab line does not prove it is syntactically valid. Creating an nftables rule does not prove packets traverse it in both directions. Extending an LVM logical volume does not automatically grow every filesystem. Use the tool that inspects each layer and reproduce the requested outcome.
Work narrowly. Before editing, inspect the current file and related state. Preserve permissions and ownership. Validate syntax where the tool supports it. Keep an independent recovery channel before remote-access or firewall changes. Do not solve one task by deleting unrelated configuration or disabling a security control globally.
Domain 1: Operations Deployment
Processes and systemd
Process diagnosis starts with identity, PID and parent, state, command line, resource use, open files, sockets, cgroup or unit, and logs. A high CPU process differs from a blocked I/O process. A zombie has already exited and needs its parent to collect status. SIGTERM gives software an opportunity to clean up; SIGKILL is a final forced stop and cannot be handled.
systemd distinguishes unit-file enablement from runtime activation. status summarizes recent state and logs; journalctl can retrieve earlier boots and invocations. daemon-reload rereads unit definitions after edits, while reload asks a service to reread its own configuration if supported. Use dependencies, ordering, restart policy, user and group, environment, working directory, resource controls, and filesystem protections intentionally. A timer can activate a service with integrated logs and dependency handling.
Kernel, packages, containers, VMs, and SELinux
Many runtime kernel tunables are exposed under /proc/sys and through sysctl. Test a nonpersistent value first where appropriate, understand the effect, then place the persistent setting in a supported configuration and verify after reboot. A setting that appears in a file but is overridden or invalid is not complete.
Package administration includes discovering the correct package, validating repository configuration and signatures, reviewing dependencies and proposed actions, changing software in an authorized window, and verifying package plus service state. Signature failure may be caused by time, key rotation, stale metadata, misconfiguration, or tampering. Restore trust rather than disabling verification.
A container image is packaged content; a container is a runtime instance with additional state and configuration. Practice image identity, ports, networks, volumes, environment, process identity, resource limits, logs, stop behavior, and cleanup. Containers commonly share the host kernel, so they are not miniature physical machines.
For libvirt, understand domain definitions, storage pools and volumes, virtual networks, autostart, console access, and logs. A moved disk image can fail because the domain still points to the old path, the hypervisor service cannot read it, or mandatory access labels do not match. Inspect before recreating the guest.
SELinux should remain enforcing in the completed solution. Use audit denials to determine whether a file has the wrong context, a service needs an established Boolean, a nonstandard port needs the correct type, or a narrow policy is genuinely required. Permanent permissive mode hides the defect and removes defense in depth.
Domain 2: Networking
Start with link, address, neighbor, route, DNS, socket, firewall, and application layers. If local-subnet traffic works but remote traffic fails, inspect routes and gateway state. If an IP works but a name does not, inspect resolver configuration, nameserver reachability, search behavior, and record results. If a socket listens locally but is unreachable remotely, check bind address, route, firewall, service policy, and return path.
IPv6 link-local addressing appears automatically on many interfaces but does not provide a global prefix or default route. Router Advertisements commonly supply prefix and default-router information, while DHCPv6 roles vary by design. Inspect actual addresses, routes, neighbors, and RA or DHCP behavior rather than applying an IPv4 mental model unchanged.
SSH, firewall, NAT, and routing
OpenSSH public-key login depends on the user account, server policy, authorized_keys content, home and .ssh ownership and modes, key algorithm, and logs. Test a second authorized session before disabling password access or closing the current channel. Keep private keys on the client and protect them.
For nftables or another installed packet-filter framework, stage policy safely. Preserve established flows where required, add the exact administration and service permits, test from the intended source, then remove broad rules. Record counters and persistent rule loading. Do not edit the firewall over the only remote session without console recovery.
A Linux router needs IP forwarding, valid forward and return routes, permitted forwarding policy, and—only where design requires it—NAT. NAT rules should match exact internal sources and egress interfaces. One successful outbound packet does not prove return policy or connection tracking.
Bonds, bridges, time, and reverse proxies
A bond combines links according to a mode; some modes require compatible switch configuration. A bridge forwards Layer 2 frames among attached interfaces, such as VM taps and an uplink. Place Layer 3 identity on the logical layer required by the design, not independently on every member. Test member loss and ensure no unintended loop or production bridge exists.
Time synchronization supports TLS validity, log correlation, scheduling, and distributed authentication. Verify source, reachability, offset, and synchronization state. A reverse proxy adds upstream address, protocol, DNS, TLS trust, service identity, firewall, and backend health dependencies. A 502 is evidence of an upstream problem, not a reason to reformat storage.
Domain 3: Storage
LVM and filesystems
LVM builds physical volumes, volume groups, and logical volumes. Confirm block-device identity before destructive commands. After creating a logical volume, add the required filesystem or swap layer. Persist mounts with an appropriate stable identifier and validate fstab before reboot. The directory is only the attachment point; making it larger does not expand storage.
When growing an LVM-backed filesystem, confirm free extents and backups, extend the logical volume, grow the filesystem with its supported tool and online or offline requirements, then verify both layers. Shrinking is more dangerous and not universally supported; do not infer symmetry from growth commands.
The Linux VFS presents a common interface over different filesystem implementations. Inodes describe filesystem objects, and directory entries map names to inodes. A filesystem can run out of inodes while free data blocks remain. Hard links share an inode; symbolic links store a path reference. Mount options, permissions, ACLs, labels, and application behavior all affect access.
Capacity, performance, remote storage, and recovery
df reports filesystem allocation; du walks reachable pathnames. They can disagree when a running process holds an unlinked file open. Locate the descriptor and restart or rotate the owner safely. Also monitor bytes, inodes, I/O latency, queue depth, throughput, utilization, and kernel errors. High latency with idle CPU may point toward storage waits or remote dependencies.
Swap requires a valid swap area, runtime activation, and persistent configuration if it should survive reboot. It can absorb memory pressure but is much slower than RAM and does not fix leaks. Automounters mount paths on demand and can expire them, reducing boot coupling to unavailable remote storage.
NFS mount behavior requires deliberate choices about identity mapping, exports, firewall, hard or soft semantics, timeouts, retries, and write integrity. There is no universal safest timeout. For filesystem repair, identify the exact device and filesystem, stop writes or unmount where documented, preserve recoverable data, use the filesystem-specific tool, and review results. Never run random repair utilities against the mounted root filesystem.
Domain 4: Essential Commands
Shell fluency includes redirection, pipelines, quoting, variables, command substitution, exit status, conditional execution, loops, functions, and text tools. A pipe connects standard output to the next command's standard input. Scripts must still detect failure in earlier stages. Quote expansions to avoid unintended splitting and globbing, but remember that quoting does not validate whether a path is safe.
Use grep for patterns, find for filesystem selection, sort and uniq for ordered grouping, cut or awk for fields, sed for controlled transformations, and diff for comparison. Scope commands so they do not traverse sensitive or enormous trees accidentally. Preview destructive selections before acting.
Permissions require mode bits, ownership, directory execute semantics, umask, setgid, sticky behavior, and ACLs. A setgid collaboration directory helps new files inherit the group. The sticky bit limits deletion in shared writable directories. ACL masks can silently narrow named entries. Verify effective access as the intended user.
Basic Git operations support configuration history: status, diff, add, commit, log, branch, switch, merge, pull or fetch, and revert. Review diffs before staging. Resolve merge conflicts according to intended system state, then validate the full result. Never push unresolved conflict markers or secrets.
TLS work includes generating or obtaining appropriate keys and certificates, configuring a service, protecting private keys, validating the chain, checking dates and usages, and matching the hostname or IP against Subject Alternative Name. Disabling verification to make a test pass hides the core error.
Domain 5: Users and Groups
Manage account creation, UID, primary and supplementary groups, shell, home, password or lock state, expiry, and removal. New group membership generally takes effect in a new login context. Service accounts should have only the shell, home, groups, files, and resources their service needs.
Offboarding should lock or revoke access promptly, then inventory files, processes, keys, timers, cron jobs, services, and ownership before transfer or deletion. Blind removal can destroy required data and leave scheduled work or orphaned files.
System-wide and personal profiles load differently for login, interactive, and noninteractive shells. Place common nonsecret environment settings in an appropriate system-wide mechanism and verify actual loading. Resource limits can be applied through PAM or systemd depending on the process path; verify the effective value, not only the configuration file.
POSIX ACLs add named-user and group permissions plus default inheritance on directories. The mask constrains effective permissions in the group class. Central identity commonly separates NSS lookup from PAM authentication and account policy. An LDAP user can appear in getent but still fail because of authentication, account restrictions, TLS trust, home creation, shell, or service access rules.
Three projects that build administrator judgment
The production-style service host combines package trust, dedicated identities, systemd services and timers, resource limits, OpenSSH, TLS, SELinux, process and socket inspection, and recovery from certificate, context, capacity, unit, and boot faults. It teaches that a running service is not necessarily enabled, secured, persistent, or healthy.
The dual-stack gateway and reverse-proxy project uses isolated VMs or namespaces for IPv4 and IPv6, DNS, time, static routes, forwarding, nftables, NAT, bonds, bridges, SSH, proxying, and bounded packet captures. Failure injection includes missing return routes, DNS and time outages, link loss, firewall mistakes, MTU mismatch, and wrong upstream protocol.
The storage and identity project builds PVs, a VG, LVs, filesystems, swap, persistent mounts, online growth where supported, capacity metrics, ACL collaboration, limits, an LDAP-style local fixture, NFS automount, backup and restore. It then injects inode exhaustion, deleted-open files, wrong UUIDs, ACL-mask constraints, remote-service outages, and a safe filesystem-repair exercise.
A nine-week preparation plan
| Weeks | Focus | Evidence |
|---|---|---|
| 1–2 | Shell, files, permissions, processes, systemd, logs, timers, and Git | Command journal, unit files, permission matrix, fault notes |
| 3–4 | Packages, kernel parameters, containers, VMs, SELinux, and recovery | Trusted package path, persistent settings, enforced denials, recovery timeline |
| 5–6 | IPv4/IPv6, DNS, time, SSH, routes, filtering, NAT, bonds, bridges, proxies | Path diagram, route and rule tests, socket and capture evidence |
| 7–8 | LVM, filesystems, swap, NFS, automount, users, groups, ACLs, limits, LDAP | Layered storage report, ACL tests, identity and restore evidence |
| 9+ | Three projects, 50 scenarios, 40 cards, and repeated two-hour rehearsals | Persistent results, failure recovery, cleanup, and timing review |
Use the five-phase LFCS roadmap as a checklist. Review 40 flashcards, but reproduce each distinction on a VM. Work through the 50 original scenarios and then perform the equivalent inspection or configuration safely.
Performance-based exam strategy
Read the requested end state and the designated host before typing. Inspect current state. Decide which runtime and persistent layers must change. Make the smallest edit. Validate syntax, state, and functional outcome. If the task requires future behavior, verify persistence through the least disruptive valid method.
Use manual pages and installed distribution documentation efficiently during authorized practice. Search for the exact option, example, configuration path, exit behavior, and related pages. Build muscle memory around help systems rather than memorizing every flag. Verify current exam rules for permitted resources instead of assuming a blog's old description applies.
Keep context visible when moving among hosts. Use hostname and prompt checks. Avoid destructive work on the base host. Do not reboot a system unless the task and environment permit it. Preserve enough time to inspect completed outcomes, but do not undo working state with speculative last-minute changes.
When stuck, return to layers. For a service: process, unit, configuration, dependency, socket, firewall, client. For storage: device, LVM, filesystem, mount, permission, application. For identity: NSS, PAM, account, group, ACL, service. For networking: link, address, neighbor, route, DNS, socket, firewall, application, return path.
Official references
- Linux Foundation Certified System Administrator
- LFCS important instructions
- Linux Foundation candidate handbook
- Linux kernel sysctl documentation
- Linux Virtual File System overview
- systemctl documentation
- OpenSSH manuals
- LVM manual
- Git reference
Continue preparation
- LFCS roadmap
- 50 LFCS scenarios
- 40 LFCS flashcards
- Three LFCS projects
- RHCSA roadmap
- CKA roadmap
- All roadmaps
- Editorial policy
Frequently asked questions
How long is the LFCS exam?
The Linux Foundation lists a two-hour duration. Verify current delivery and accommodation details through official resources.
What is the LFCS format?
It is an online, proctored, performance-based exam in which candidates solve administration problems from the Linux command line.
What are the domain weights?
Operations Deployment 25%, Networking 25%, Storage 20%, Essential Commands 20%, and Users and Groups 10%.
Does this guide state a live task count or passing score?
No. Use the current official certification page, instructions, and candidate handbook for applicable logistics and policies.
What should be checked before exam day?
Review the official system requirements, candidate handbook, important instructions, identification and testing-space rules, permitted-resource rules, and the environment guidance currently published by the Linux Foundation.
Are these practice scenarios recalled exam tasks?
No. They are independently written educational scenarios grounded in public domains and official Linux documentation.