LFCS LINUX FOUNDATION CERTIFIED SYSTEM ADMINISTRATOR Exam Topics and Questions

This topic sets the baseline for everything else on the exam. The name understates the scope: you are not just running commands, you are diagnosing live systems, chasing down disk pressure, managing certificates, and keeping services healthy. Candidates who treat this as revision of familiar shell work tend to lose marks on the service and SSL sub-areas, where the detail required is sharper than most people expect from a topic called "essential".

– Services, performance, and constraints

Creating and configuring services means working with systemd units at a level beyond simple start and stop. You need to know how to write and modify unit files, set dependencies, and confirm that a service survives a reboot in the state you left it. Troubleshooting service failures means reading journal output purposefully, not just scrolling until something looks wrong. Performance monitoring sits alongside this: you are expected to interpret what tools like top, iostat, and journalctl are telling you and act on it. Determining application and service-specific constraints means understanding resource controls such as CPUQuota and MemoryLimit inside unit files, because a service that starts but behaves badly under load is still broken. Disk space troubleshooting is practical: find what is consuming space, identify which filesystem is full, and clear or redirect the problem without losing data. Each of these demands a command-level answer, not a conceptual one.

– Git operations and SSL certificates

Basic Git operations appear here because system administrators are expected to manage configuration and scripts stored in version-controlled repositories. The scope is practical: initialise a repo, clone, commit, push, pull, resolve a straightforward conflict, and read history. You are not being examined on advanced branching strategy. SSL certificates are the area most candidates underestimate. Working with certificates means generating keys and certificate signing requests, installing certificates in the right locations, verifying chain validity, and checking expiry dates from the command line using openssl. You need to know how to inspect a certificate to confirm what it contains, and how to configure a service to use it. The exam tests whether you can do these things on a running system, not whether you can describe the TLS handshake. Errors in certificate paths and permission settings are the most common source of lost marks here.

How Essential Commands is tested

At 20% of the exam this topic appears often enough that gaps compound quickly. Items tend to be scenario-based: a service is failing, a disk is full, a certificate is rejected, and you must identify the cause and apply a fix. The demand is precision. Knowing that journalctl is the right tool is not enough; items reward knowing which flags narrow output to a specific unit, a specific boot, or a specific time window. The SSL sub-area consistently catches candidates who know the concept but have not practised the openssl command syntax for inspecting and verifying certificates. Disk space questions penalise candidates who reach for df without following up with du or lsof to find the actual offender. Git items are usually the most straightforward, but only if you have actually used the commands rather than read about them. The pattern across this topic is that partial knowledge gets you to the right area but the wrong answer; the marks go to candidates who know the exact flag or file path.

After the broad command work of the first topic, this one narrows to identity and access on a local system and beyond. At 10% it is not the largest slice of the exam, but it contains several sub-areas where a single missed detail, a wrong flag on useradd or a misconfigured ACL mask, produces a result that looks correct until something tries to use it. The LDAP sub-area in particular is where candidates who have only worked in smaller environments tend to lose marks.

– Local accounts and the environment

Managing local users and groups means more than creating accounts. You need to set and modify passwords, lock and unlock accounts, assign supplementary groups, and understand the difference between the files that drive all of this: passwd, shadow, group, and gshadow. The exam tests whether you reach for the right tool, useradd versus usermod versus groupmod, and whether you know what each flag does without guessing. Environment profiles sit alongside this because the distinction between a file in /etc/profile.d, a user's .bash_profile, and /etc/environment matters when you need a setting to apply in a specific scope. Getting the scope wrong means the setting either applies too broadly or not at all, and the exam will test that boundary. Resource limits via /etc/security/limits.conf and the PAM limits module require you to know both the syntax and which limit types, hard versus soft, do what.

– ACLs and LDAP integration

Access control lists extend standard Unix permissions without replacing them, and the exam tests both. You need to use getfacl and setfacl correctly, understand how the ACL mask interacts with named user and group entries, and know that a chmod on a file with ACLs recalculates the mask. Candidates who have only set ACLs and never inspected or debugged them tend to misjudge what the effective permissions will be. Configuring the system to use LDAP user and group accounts is the most infrastructure-heavy sub-area in this topic. You are expected to configure the relevant NSS and PAM components so that LDAP-defined users can authenticate and appear in standard lookups. The detail that matters is knowing which files to edit and in what order, because a misconfigured nsswitch.conf or a missing PAM module produces a system that partially works, which is harder to diagnose than one that fails completely.

How Users and Groups is tested

Items in this topic reward accuracy over breadth. A question about user creation is not checking whether you know useradd exists; it is checking whether you know the specific flag for setting a home directory, an expiry date, or a shell, and what happens when you omit one. The ACL mask is a reliable trap: candidates who understand named ACL entries but have not worked through what happens to effective permissions after a chmod will pick an answer that looks right but describes a different outcome. LDAP items demand that you know the configuration layer being asked about. The exam does not stay at the conceptual level of "configure LDAP authentication"; it goes to the specific files and the specific directives inside them. Resource limit items often test the boundary between hard and soft limits and what a user can and cannot do with each. The topic is narrow enough that thorough preparation covers it completely, but surface-level familiarity leaves several reliable drop points exposed.

Networking carries the largest share of the exam alongside Operations Deployment, and it earns that weight. The sub-topics range from IP addressing and DNS resolution through time synchronisation, SSH hardening, firewall rules, routing, bonding, bridging, and finally reverse proxies and load balancers. Few candidates are equally comfortable across all of them. The cost of a weak area here is high: missing several related items in a 25% topic moves the score noticeably. Identify your gaps in this domain before exam day, not during it.

– IP configuration, DNS, and time

Configuring IPv4 and IPv6 networking on a modern Linux system means working with NetworkManager or systemd-networkd depending on the distribution, and knowing which files and commands are authoritative. The exam will not accept an answer that works temporarily if the question asks for persistence. Hostname resolution covers both /etc/hosts and DNS resolver configuration, and you need to know the order in which they are consulted and how to change it. IPv6 address types, link-local versus global unicast, appear in scenario questions where the address scope determines whether a route or a connection will work. Time synchronisation with chrony or systemd-timesyncd is tested at the configuration level: setting servers, verifying synchronisation status, and understanding why a system that is running ntpd might still drift. The tools for checking sync status are as important as the config files themselves.

– SSH, packet filtering, and NAT

SSH configuration is split between the server side and the client side, and the exam tests both. On the server, the relevant directives in sshd_config control authentication methods, port, permitted users, and forwarding. On the client side, ~/.ssh/config and key-based authentication setup are fair game. Packet filtering means nftables or iptables depending on the system, and you need to be able to write and read rules, understand chain order, and configure NAT. Port redirection with DNAT is a specific scenario that appears regularly: the question describes a desired traffic flow and you need to construct the rule that achieves it. Candidates who know the concept but have not practised the rule syntax lose marks here because the syntax is precise and an almost-correct rule does nothing. NAT for outbound traffic requires understanding MASQUERADE versus SNAT and when each applies.

– Routing, bonding, bridging, and proxies

Static routing is tested at the level of adding persistent routes, verifying the routing table, and understanding the difference between a route added with ip route and one written into a network configuration file. The persistence angle is the most common trap: a route that works until the next reboot is wrong if the question asks for a permanent change. Bridge and bonding devices require you to know the configuration method for the distribution, what bonding modes exist and what each achieves in terms of redundancy or throughput, and how to verify that a bond or bridge is operating correctly. Reverse proxies and load balancers, typically nginx or HAProxy in this context, are tested at the configuration level. You need to know how to define an upstream group, set a balancing algorithm, and configure the proxy pass. The exam does not go deep into tuning, but it does expect you to produce a working configuration for a described scenario.

How Networking is tested

At 25% this topic will appear throughout your exam. Items consistently test persistence: a change that survives a reboot versus one that does not is the single most common axis of discrimination in networking questions. Items reward knowing the exact file or command that makes a change permanent on the system described. The firewall and NAT sub-area is where syntax precision matters most. Items describe a traffic requirement and the strongest response is one that achieves exactly the described behaviour with a correctly formed rule, not one that describes the right concept with a plausible-looking but malformed command. SSH items often present a specific access restriction scenario and reward knowing which sshd_config directive controls it. Bonding mode questions test whether you understand what mode 1 versus mode 4 actually does to traffic, not just that bonding exists. Proxy and load balancer items tend to be configuration-completion style, where you identify what is missing from a partial config to make it functional. The breadth of this topic means that targeted practice across every sub-area is the only reliable preparation.

This topic shares the top weight with Networking but has a different character: where Networking is wide, Operations Deployment is deep. Kernel parameters, process management, job scheduling, package handling, failure recovery, virtualisation, containers, and mandatory access control are all here. Each sub-area has enough depth to absorb a candidate who has not deliberately capped their preparation. The areas that most often cause trouble are SELinux and container configuration, both of which require hands-on familiarity that reading alone does not build.

– Kernel parameters and process management

Kernel parameters via sysctl are tested in both their transient and persistent forms. Setting a parameter with sysctl -w takes effect immediately but does not survive a reboot; writing it to /etc/sysctl.d/ does. The exam will specify which it wants, and giving the other one is a full miss. Process and service management in this context means more than systemctl start and stop. You need to diagnose a process that is consuming unexpected resources, identify orphaned or zombie processes, send the right signal for the right purpose, and adjust process priority with nice and renice. Job scheduling covers both cron and systemd timers. The syntax differences between crontab fields and a systemd OnCalendar expression are tested, and so is the question of which tool is more appropriate for a given scenario. Candidates who know only cron and have not worked with systemd timers will find some items harder than they should be.

– Packages, repositories, and failure recovery

Software package management is tested across the full lifecycle: searching for a package, installing it, verifying its integrity, pinning a version, and managing the repository configuration that makes it available. The exam covers both RPM-based and Debian-based tooling, so you need to be comfortable with dnf/rpm and apt/dpkg. Validating a package means checking GPG signatures and understanding what a repository key does. Recovery from hardware, OS, or filesystem failures is the sub-area with the highest stakes in practice and on the exam. You need to know how to boot into a rescue or emergency target, mount filesystems manually, repair a broken bootloader with grub2-install or update-grub, and run fsck safely. The sequence matters: running fsck on a mounted filesystem is wrong, and the exam tests whether you know that. Recovery items reward methodical, ordered thinking over speed.

– Virtualisation and containers

Managing virtual machines with libvirt means using virsh to list, start, stop, define, and modify VMs, and understanding the XML-based domain definition well enough to make a targeted change. The exam does not expect deep KVM internals, but it does expect you to perform administrative tasks on a running virtualisation host without reaching for a GUI. Container configuration covers creating, running, inspecting, and stopping containers with either Docker or Podman. You need to know how to map ports, bind-mount volumes, pass environment variables, and manage container lifecycle. The exam tests whether you can produce a working container invocation for a described scenario, not whether you can architect a multi-service deployment. Networking between containers and the host is a common scenario. Candidates who have only used containers through higher-level tooling and have not worked directly with the container runtime commands will find the precision required here difficult.

– Mandatory access control with SELinux

SELinux is the sub-area where the most candidates lose marks in this topic. The exam tests practical SELinux administration: checking the current mode with getenforce, switching between enforcing and permissive with setenforce, making mode changes persistent in /etc/selinux/config, and using audit2allow and audit2why to diagnose denials. Relabelling files with chcon and restorecon, managing booleans with getsebool and setsebool, and understanding why a service that works in permissive mode fails in enforcing mode are all in scope. The trap is that many candidates know SELinux exists and know the concepts at a high level but have not worked through an actual denial and traced it to a file context or a boolean. Items reward the candidate who can read an AVC denial in the audit log and identify the specific change needed to resolve it, not the one who knows that SELinux uses labels.

How Operations Deployment is tested

At 25% this topic is as consequential as Networking, and its items tend to demand more decision-making. Kernel parameter items almost always test persistence, the same trap as in Networking but in a different configuration layer. Process management items reward knowing which signal achieves a specific effect, not just that signals exist. Package management items test the full command including flags; knowing the tool name without knowing the flag for signature verification or version locking is not enough. Recovery items are the most sequential: items reward a response that performs steps in the right order, because the wrong order either fails or causes further damage. SELinux items are the most reliably discriminating in this topic. Candidates who have practised SELinux troubleshooting on a real system will find these items straightforward; those who have only read about it will find the specificity of the options difficult to navigate. Container items test command construction for a described scenario, and the marks go to the response that produces a correct, complete invocation. Broad coverage without depth in any single area is the most common preparation mistake for this topic.

Storage closes the exam at 20% and brings together filesystem management, LVM, swap, remote storage, automounting, and performance monitoring. After the process and deployment focus of the previous topic, this one returns to configuration files and command-line tools applied to block devices and filesystems. The area where candidates most often drop marks is LVM, where the sequence of operations and the exact commands for resizing, extending, and verifying volumes need to be precise. Automounting and remote filesystems are the second most common source of avoidable losses.

– LVM and the virtual filesystem

LVM administration is tested across the full stack: physical volumes with pvcreate and pvdisplay, volume groups with vgcreate and vgextend, and logical volumes with lvcreate, lvextend, and lvreduce. The exam tests whether you can extend a logical volume and then resize the filesystem on top of it, and it tests whether you know that reducing an ext4 filesystem requires unmounting it first while XFS cannot be shrunk at all. These are the kinds of detail that separate a candidate who has managed LVM from one who has read about it. The virtual filesystem layer means understanding the VFS abstraction: how the kernel presents a unified filesystem tree regardless of the underlying device type, how mount options interact with filesystem behaviour, and how /proc and /sys fit into this picture. Items in this sub-area tend to test the effect of specific mount options rather than the concept of mounting itself.

– Filesystem creation, swap, and automounting

Creating and troubleshooting filesystems means knowing mkfs variants for ext4, XFS, and btrfs, understanding what tune2fs does and when to use it, and running fsck correctly on an unmounted device. The exam will give you a scenario where something is wrong with a filesystem and ask you to identify the right remediation step. Swap configuration covers creating a swap partition or file, activating it with swapon, setting priority when multiple swap areas exist, and making it persistent in /etc/fstab. The priority flag is a detail many candidates overlook until they see it in a question. Automounting with autofs requires knowing the master map and the indirect or direct map syntax, and understanding the difference between autofs-managed mounts and static /etc/fstab entries. A misconfigured autofs map that fails silently is harder to debug than a mount that fails loudly, and the exam tests whether you know where to look.

– Remote filesystems, block devices, and storage performance

Remote filesystems in scope include NFS and, depending on the system, iSCSI for network block devices. NFS configuration means knowing both the server side, /etc/exports and exportfs, and the client side, the mount options that affect performance and reliability such as hard versus soft mounts and the rsize and wsize parameters. iSCSI as a network block device requires knowing the initiator configuration, discovering targets, and logging in. The exam does not go deep into iSCSI internals, but it does expect you to connect a client to a target and use the resulting block device. Storage performance monitoring means using iostat, iotop, and similar tools to identify a device or process causing I/O pressure, then interpreting the output to distinguish between throughput saturation and latency issues. Items reward knowing what each column in iostat output represents, not just that the tool exists.

How Storage is tested

Storage items are precise and sequential. LVM questions reward knowing the exact command sequence for a given outcome: creating a volume group before a logical volume, extending the VFS-level filesystem after extending the logical volume, and choosing the right tool for the filesystem type in use. Getting the sequence right but the filesystem tool wrong is still a loss. Swap items often test the fstab entry format and the priority option, both of which need to be exact. Automount items test map syntax and the behaviour of autofs when a map entry is malformed. Remote filesystem items reward knowing the mount options that affect reliability under network interruption, because a soft NFS mount and a hard one behave differently when the server becomes unreachable, and the exam will present that scenario. Performance monitoring items ask you to interpret tool output and identify the bottleneck, which means you need to have used the tools, not just know their names. The overall pattern in Storage is that the exam rewards candidates who have worked through each operation end-to-end on a real or virtual system, because the questions sit at the level of detail that only hands-on practice makes automatic.