LFCS — Linux Foundation Certified System Administrator

Every certification on this course's certifications hub — the AWS exam, the CKA, the Azure and GCP exams elsewhere on this page — quietly assumes you can already operate a Linux box: read a log with journalctl, fix a permission with chmod, find out why a disk filled up. None of those exams test that directly. The Linux Foundation Certified System Administrator is the one that does, and it does it the hard way: no multiple choice, a live terminal, real tasks on a real machine, graded on whether the system ends up correct. It's also deliberately distro-agnostic — the skills it certifies don't belong to Ubuntu, openSUSE, RHEL, or any single vendor's cloud. Below: what it actually is, the six official domains and weights, the real commands behind each one, and why this is the certification worth having before any of the cloud-specific professional exams on this course, not after.

What the LFCS is, and who it's for

☺ Like you're 10: A hands-on test on a real Linux terminal — no questions with four bubbles to fill in, just real broken and unconfigured things to fix.

The Linux Foundation Certified System Administrator (LFCS) is The Linux Foundation's entry point into professional Linux system administration — the operational half of the same organization that runs the CKA. It certifies the general-purpose skill set every Linux box needs regardless of what runs on top of it: managing users and permissions, keeping services running, configuring networking, and managing storage. It has existed since 2014 and, unlike most of the certifications elsewhere on this course, it certifies no single vendor's product — not a cloud, not a config-management tool, not a container platform. It certifies the operating system itself.

Performance-based, not multiple choice

Like the CKA, there is no question bank here. You're dropped into a live, browser-based terminal against a real virtual machine and handed a sequence of hands-on tasks — create a user with a specific UID, extend a logical volume without unmounting it, configure a service to start on boot and open the firewall port it needs. Grading is on the end state of the machine when time runs out, not on the elegance of how you got there, which means the same two consequences the CKA teaches: speed is a real skill, and an unverified change is a change you can't be sure you made. One meaningful difference from the CKA: LFCS is closed-book — there's no allowed documentation tab, which puts more weight on commands and flags you actually remember rather than ones you can look up mid-task.

Distro-agnostic — but you still pick one

At the start of the exam you choose which Linux environment to work in — historically Ubuntu or openSUSE Leap — and every task runs against that one distribution for the full session. "Distro-agnostic" describes the skill set, not the exam mechanics: the concepts (users, permissions, systemd units, LVM, firewalls) transfer identically across the family, but the exact package-manager invocation doesn't — apt install on Ubuntu, zypper install on openSUSE. Pick the one you already have muscle memory in rather than the one you feel obligated to learn for the exam; the domains being tested are the same either way.

Who should sit it

It targets working system administrators, and — increasingly — DevOps and platform engineers whose Linux fluency was picked up sideways, from Stack Overflow answers and copy-pasted Dockerfiles, rather than from actually administering a box day to day. If you can already explain the difference between a hard link and a symlink, extend a logical volume under load, and read a journalctl failure without searching for the flag syntax, this exam will mostly confirm what you know. If any of those made you pause, that pause is exactly what this certification exists to close, and closing it pays off on every other exam on this course's certifications hub, not just this one.

↗ Linux Foundation official LFCS page

The official domains and weights

☺ Like you're 10: Six topics, and — like the CKA — they're not equal. A quarter of the whole exam is just "the everyday commands," and the smallest slice is user accounts.

These are the six domains The Linux Foundation publishes for the current LFCS curriculum, weighted and summing to 100%. As with every exam on this course, weights and sub-bullets get revised between curriculum versions — treat the breakdown below as a strong planning baseline and confirm the current version before you build a study plan entirely around it.

The shape worth noticing: Essential Commands and Operation of Running Systems together are 45% — almost half the exam is general command-line fluency and keeping a system alive, before a single domain-specific configuration task even starts. The competencies below are a close, study-oriented paraphrase of what The Linux Foundation publishes for each domain, not a verbatim quote.

25% — Essential Commands

• Work productively at the command line — piping, redirection, environment variables, command history and expansion
• Search, transform and filter text with grep, sed, awk, and related tools
• Manage and diagnose running processes, including signals, priority, and job control
• Use SSH for remote administration, including key-based authentication
• Install, configure, and troubleshoot the GRUB2 bootloader
• Query and report basic system information

20% — Operation of Running Systems

• Boot, reboot, and shut down a system safely; alter the systemd boot target
• Diagnose and manage system and application services under systemd
• Locate, read, and manage system log files, including the systemd journal
• Schedule tasks for future or recurring execution with cron, at, and systemd timers
• Install, update, and remove software packages using the distribution's own package manager

20% — Service Configuration

• Configure and maintain a web server
• Configure a file-sharing service (NFS or Samba) and an FTP service
• Configure a caching DNS service and basic mail relay (SMTP) behavior
• Set up and configure a database server
• Configure time synchronization, client and server
• Configure and use a basic container platform

13% — Storage Management

• List, create, and delete partitions on a storage device
• Create and manage LVM storage — physical volumes, volume groups, logical volumes
• Create, mount, and manage filesystems of different types, including at boot via /etc/fstab
• Configure and manage swap space
• Create and manage encrypted storage volumes
• Configure disk quotas for users and groups

12% — Networking

• Configure networking statically and dynamically — addressing, gateway, and name resolution
• Configure and manage network interfaces with the distribution's own tooling
• Implement basic packet-filtering firewall rules
• List and identify processes listening on network ports
• Perform basic connectivity troubleshooting

10% — User and Group Management

• Create, modify, and delete user accounts and groups
• Query and manage group membership and account-related system files
• Configure default user environment settings for new accounts
• Configure and use sudo for privilege delegation

Notice what's absent from this list entirely: nothing here names a cloud provider, a container orchestrator, or a configuration-management tool. That's not an oversight — it's the whole point of a distro-agnostic exam. Everything above is what a box needs regardless of who's renting it to you.

What you actually need to be able to do

☺ Like you're 10: Here's the real work behind each domain — the commands your fingers need to produce without stopping to look anything up.

Essential commands and process control

This domain rewards fluency over depth: text processing, process signals, and SSH need to be reflexive, not researched mid-task.

# text processing — the exam's favorite quiet skill
grep -c "ERROR" /var/log/app.log                    # count matching lines
awk -F: '$3 >= 1000 {print $1}' /etc/passwd          # non-system users by UID
sed -n '/^Failed password/p' /var/log/auth.log | tail -20

# process control
ps aux --sort=-%cpu | head                          # top CPU consumers
kill -TERM 4821                                      # ask nicely first
kill -9 4821                                          # SIGKILL, last resort
nice -n 10 ./batch-job.sh                             # start with lower priority
renice -n 5 -p 4821                                   # reprioritize a running process
jobs -l; bg %1; fg %1; disown %1                      # job control basics

# SSH key auth — no password prompts once this is right
ssh-keygen -t ed25519 -C "sysadmin@node1"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@10.0.1.15
ssh -i ~/.ssh/id_ed25519 deploy@10.0.1.15

Operating a running system

systemd is the backbone of this domain: units, targets, the journal, and scheduled jobs. The exam expects you to diagnose a failed service from its unit file and its logs, not just restart it and hope.

systemctl status nginx                                # is it running, and why not
systemctl enable --now nginx                          # start now AND on every future boot
journalctl -u nginx -n 50 --no-pager                  # last 50 lines for this unit
journalctl -u nginx --since "10 min ago" -p err       # errors only, recent window
systemctl get-default                                 # current boot target
systemctl set-default multi-user.target               # boot to CLI, not a GUI

# scheduled work — three mechanisms, know when each applies
crontab -e                                             # per-user recurring jobs
echo "shutdown -h now" | at 23:00                      # one-shot, future execution
systemctl edit --force --full backup.timer            # systemd timer: unit-native, loggable

# package management — the one command that differs by distro
apt update && apt install -y nginx                    # Ubuntu / Debian family
zypper refresh && zypper install -y nginx              # openSUSE

Users, groups, and sudo

The smallest domain by weight, and the most mechanical — but the exam still expects the files behind the commands to make sense, not just the commands themselves.

useradd -m -s /bin/bash -u 2001 deploy                 # home dir, shell, explicit UID
passwd deploy
groupadd release-managers
usermod -aG release-managers deploy                    # -a = append, never drop existing groups
id deploy; groups deploy

visudo                                                 # always edit sudoers through visudo
# %release-managers ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app.service

chage -l deploy                                        # password aging / expiry policy
tail -3 /etc/passwd /etc/shadow /etc/group             # the three files behind every command above

Networking

Addressing, resolution, and a basic firewall — plus the reflex to prove connectivity rather than assume it.

ip addr show                                           # current addressing
ip route add default via 10.0.1.1                      # default gateway, imperative
ip route show

nmcli con show                                         # NetworkManager-based systems
nmcli con mod eth0 ipv4.addresses 10.0.1.50/24 ipv4.gateway 10.0.1.1 ipv4.method manual
nmcli con up eth0

ss -tulpn                                              # what's listening, and which process
ping -c 4 10.0.1.1; traceroute 10.0.1.1
dig +short api.internal.example.com

# a minimal packet filter — allow SSH and HTTP, deny everything else inbound
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --reload
firewall-cmd --list-all

Service configuration

This domain is breadth, not depth — you're expected to stand up a working, minimal instance of several common services, not tune any one of them.

# NFS export — server side
echo "/srv/shared 10.0.1.0/24(rw,sync,no_subtree_check)" >> /etc/exports
exportfs -ra
showmount -e localhost

# time sync — chrony is the modern default on both distro families
chronyc sources -v
chronyc tracking

# a minimal container platform check — LFCS expects you can run one, not orchestrate a fleet
docker run -d --name web -p 8080:80 nginx:alpine
docker ps; docker logs web

Storage management

LVM end to end — create, mount, and later extend without downtime — is the domain's centerpiece, and the sequence matters as much as any single command.

pvcreate /dev/sdb1
vgcreate vg_data /dev/sdb1
lvcreate -L 10G -n lv_app vg_data
mkfs.ext4 /dev/vg_data/lv_app

mkdir -p /srv/app
blkid /dev/vg_data/lv_app                              # get the UUID for fstab
echo "UUID=<uuid>  /srv/app  ext4  defaults  0  2" >> /etc/fstab
mount -a                                                # verify fstab is correct BEFORE rebooting

# extend a live filesystem — no unmount required for ext4/xfs online growth
lvextend -L +5G /dev/vg_data/lv_app
resize2fs /dev/vg_data/lv_app                          # ext4; use 'xfs_growfs /srv/app' for xfs

# swap, the part people forget to persist
fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo "/swapfile  none  swap  sw  0  0" >> /etc/fstab

Why LFCS underlies every cloud-vendor exam on this course

☺ Like you're 10: A cloud exam tests what you do with a Linux machine once you're renting it — never whether you actually know your way around the machine itself.

Look closely at what the professional-level cloud exams on this course's certifications hub actually assume, and a pattern shows up: every one of them puts you in front of a Linux machine and grades what you do on top of it, never whether you can operate the machine itself. That gap is exactly what LFCS closes, and it closes it once, for every cloud vendor at the same time — because the EC2 instance, the Azure VM, and the Kubernetes node all boot the same kernel underneath a different logo.

None of that is a criticism of those exams — they're testing what they're supposed to, one layer up. It just means a candidate who walks into the CKA or a cloud professional exam without ever having run lvextend under time pressure, or debugged a unit file from a raw journalctl dump, is spending exam-day cognitive budget on a skill LFCS exists to make automatic beforehand. That's the case for taking this one first, not last.

How to prepare using this site

☺ Like you're 10: This course teaches Linux fundamentals mostly by using them in service of DevOps practices — here's where each domain shows up, and where the real gap still is.

This course was written to teach DevOps practices, not to be an LFCS study guide, so the honest picture is partial coverage plus a real gap. Where it overlaps, the coverage is genuine; where it doesn't, a real VM and the official curriculum are the better teacher.

A workable four-week shape: week 1, essential commands and process/service control until systemctl and journalctl are reflexive; week 2, users, groups, sudo, and networking, all from a bare shell with no copy-paste; week 3, LVM and filesystems end to end, including at least one online extension under load; week 4, service configuration breadth — stand up one of each named service — followed by two full timed practice runs.

Exam logistics — verify these yourself before you register

☺ Like you're 10: Prices and durations drift. Read the official page the week you actually plan to pay, not a page like this one from months ago.

Where it sits, and what to do next

☺ Like you're 10: It's the floor, not a rung on any one ladder — other certifications assume you already have it, whether or not they say so out loud.

LFCS doesn't compete with a single certification on this course's certifications hub — it sits underneath all of them. The closest thing to a direct alternative is Red Hat's own RHCSA: same performance-based philosophy, same general scope, but locked to Red Hat Enterprise Linux specifically rather than distro-agnostic. Take RHCSA if your employer is a RHEL shop and the vendor-specific badge matters there; take LFCS if you want the skill certified independent of any one distribution family, which is the better default for a portfolio that also touches AWS, Azure, and GCP boxes.

Above LFCS on The Linux Foundation's own ladder sits the Linux Foundation Certified Engineer (LFCE), which goes deeper on the same operational territory — advanced networking, security, and service administration — the same "practitioner to advanced practitioner" step the CKA takes toward CKS. And nothing about LFCS is a required gate for anything else on this course: it's a recommended foundation, not a locked prerequisite, for the CKA, the Terraform Associate, or any cloud-vendor exam on the certifications hub. If you're planning a route through several certifications on this course and haven't sat any of them yet, LFCS is the one honest place to start — every exam after it gets a little easier because the Linux underneath stops being the part you're unsure about.