LFCS — the exam

The Linux Foundation Certified System Administrator (LFCS) is the odd entry on this whole shelf. It carries no CNCF logo, tests no cloud-native project by name, and is issued directly by the Linux Foundation rather than its cloud-native sub-foundation — and yet Golden Kubestronaut lists it as the sixteenth and final requirement, sitting beside eight CNCF project associates and the five-exam Kubernetes core this course assumes you already hold. It is also the only exam on the entire ladder, other than CKA itself, that hands you a live terminal instead of a multiple-choice form: two hours, a real machine, graded on the state you leave it in. And since a revision on 11 May 2023 it no longer even asks which distribution you prefer — it tests the Linux that is the same everywhere. This page is the hub: what it actually is, the five official domains and weights, a live trace of what a container really is underneath Kubernetes' abstractions, and the exam logistics as of writing.

Linux Foundation, not CNCF — and why it counts anyway

☺ Like you're 10: The CNCF is one club inside a bigger club called the Linux Foundation. This exam belongs to the bigger club, not the cloud-native one — but the bigger club's badge is still required to finish the whole set.

Every other credential on this ladder — the five Kubernetes core exams and the eight project associates covered elsewhere in this course — is a CNCF certification: written by a curriculum committee tied to a specific open-source project, branded with the CNCF mark, announced on cncf.io. LFCS has none of that. It has no sponsoring project, no maintainer-written curriculum, no CNCF logo anywhere on the certificate. It is issued straight from the Linux Foundation — the parent organization the CNCF itself lives inside — and it existed years before Kubestronaut or Golden Kubestronaut were invented, as a general-purpose Linux sysadmin credential aimed at nobody in particular running clusters.

Golden Kubestronaut bolts it on anyway, and the reasoning is sound once you say it out loud: fifteen CNCF-branded exams can certify that you understand every layer of the cloud-native stack down to the container boundary, and still say nothing about what's underneath that boundary. A Pod is not made of YAML at runtime — it's a Linux process, in namespaces, on a cgroup budget, started by a container engine that is itself a systemd unit. LFCS is the one exam on the ladder that tests the floor the other fifteen are standing on.

What LFCS shares with the CNCF pack is format kinship in one direction only: it is performance-based, exactly like CKA and ICA's hands-on half — a live terminal, real tasks, graded on final state — rather than the multiple-choice format the other seven project associates use. If you've already sat CKA, the exam-day mechanics here will feel familiar even though the subject matter has nothing to do with a cluster.

Distribution-agnostic since 11 May 2023 — what changed

☺ Like you're 10: The test used to make you pick which brand of Linux you'd be tested on. Now it doesn't — it only asks about the parts that work the same no matter which brand you're running.

Before May 2023, candidates chose a distribution family in the preparation checklist, and a meaningful slice of the exam leaned on distribution-specific package tooling. The Linux Foundation revised the exam effective 11 May 2023: distribution selection was removed entirely, and the five domains were restated in their current, distribution-agnostic form. The practical effect is that apt-versus-yum trivia is now worthless prep, while the tools that behave identically everywhere — systemd, journalctl, ip, ss, LVM, ACLs, the /proc and /sys filesystems — are exactly what gets tested.

The five official domains and their weights

☺ Like you're 10: Five topics, and two of them — running things and talking to the network — together make up half the whole test.

Unlike some of the knowledge-based exams on this ladder, the Linux Foundation does publish percentage weights for LFCS, and they're worth planning a study schedule around. The five domains below sum to exactly 100% (25 + 25 + 20 + 20 + 10), as revised 11 May 2023.

Two things to notice before you build a study plan. First: "Essential Commands" is not the beginner survival kit its name implies — it's Git, service troubleshooting, disk-space forensics, and SSL certificates, the exact problem cert-manager automates inside a cluster and that someone still has to debug by hand on a bare host. Second: Networking and Operations Deployment are each 25%, and together are half the paper — a fair reflection of where 3am pages actually come from, and precisely the ground the next two sections cover.

systemd and journald — the commands that run everything

☺ Like you're 10: One program starts almost everything on the machine, and one program writes down almost everything that happens. Learn those two and half the exam gets easier.

On any modern Linux node, systemd is PID 1 — the first process the kernel starts, and effectively the operating system's own API for starting, stopping, restarting and supervising everything else. The kubelet is a unit. The container engine is a unit. The SSH daemon is a unit. Knowing units, drop-in overrides, dependency ordering and restart policy is the difference between "the service is broken" and "containerd.service failed its start because a config key is malformed — here's the exact line."

# What's broken, and since when?
systemctl status sshd.service           # state, PID, its cgroup, last log lines
systemctl list-units --failed           # everything that failed to start
systemctl is-enabled sshd               # will it come back after a reboot?
systemctl cat sshd.service              # the EFFECTIVE unit: vendor file + drop-ins

# Override a unit WITHOUT editing the vendor file (writes a drop-in snippet)
systemctl edit sshd.service
systemctl daemon-reload && systemctl restart sshd

# journald — the one place every unit's output actually lands
journalctl -u sshd -f                          # follow one unit live
journalctl -u sshd --since "10 min ago" --no-pager
journalctl -p err -b                            # errors only, this boot
journalctl -b -1                                # the PREVIOUS boot — did it crash?
journalctl -k                                   # kernel ring buffer (dmesg) — look for OOM
journalctl --disk-usage                         # journald is a classic /var space eater

And writing a unit is examinable in its own right — "create, configure and troubleshoot services" is named directly in the Operations Deployment domain:

# /etc/systemd/system/mission-agent.service
[Unit]
Description=Mission telemetry agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mission-agent --config /etc/mission/agent.yaml
Restart=on-failure
RestartSec=5s
User=mission
MemoryMax=512M          # a cgroup v2 limit, written in systemd's own dialect
CPUQuota=50%             # ...and so is this

[Install]
WantedBy=multi-user.target

Those last two lines matter more than they look. MemoryMax and CPUQuota aren't systemd inventions — they're cgroup v2 controls with a friendlier spelling, and the same controls are what Kubernetes writes on your behalf every time you set resources.limits on a container. That link is the whole point of the next section.

Namespaces and cgroups — what a container actually is, traced live

☺ Like you're 10: A container isn't a special box. It's a normal program that's been told a small lie about what it can see, and put on a strict allowance for how much it can use.

A container is a normal Linux process that has been lied to about the world (namespaces — its own private view of PIDs, mounts, network interfaces, hostname, users and IPC) and put on a budget (cgroups — a hard cap on what it can consume, and an account of what it actually used). Kubernetes never invented either mechanism; it schedules them. So when a Pod reports OOMKilled, no Kubernetes component made that call — the kernel's cgroup memory controller did, because a cgroup crossed memory.max. Kubernetes only reported the verdict after the fact. Walking down to that evidence, rather than staring at kubectl describe pod and shrugging, is the entire skill this domain is testing.

# The Pod that starts this whole chain
resources:
  limits:
    memory: 512Mi     # kubelet turns this into a cgroup v2 file, not a suggestion

# Which cgroup is a process in? (cgroup v2 = one unified hierarchy)
cat /proc/$(pgrep -f my-app | head -1)/cgroup
systemd-cgls                        # the cgroup tree, as systemd sees it
systemd-cgtop                       # top(1), but per cgroup

# Kubernetes' pods live under the same tree — the YAML limit ends up here.
# Path depends on the kubelet's cgroup driver: 'systemd' gives kubepods.slice/,
# the older 'cgroupfs' driver gives /sys/fs/cgroup/kubepods/. Check before you guess.
ls /sys/fs/cgroup/kubepods.slice/
cat /sys/fs/cgroup/kubepods.slice/<pod-slice>/memory.max      # your resources.limits.memory
cat /sys/fs/cgroup/kubepods.slice/<pod-slice>/memory.events   # oom_kill counter -> OOMKilled
journalctl -k | grep -i "out of memory"                        # the kernel's own log line

# Namespaces: what isolation does this PID really have?
lsns -p 1234
nsenter -t 1234 -n ip addr          # run 'ip addr' INSIDE that pod's network namespace
nsenter -t 1234 -m ls /             # ...and inside its mount namespace

That nsenter trick is worth the whole domain on its own: it's how you inspect the network of a container whose image ships no debugging tools at all — the exact situation a distroless production image puts you in.

The rest of the syllabus, fast: kernel, networking, storage, users

☺ Like you're 10: The remaining three-and-a-bit domains are mostly muscle memory — the kind of thing you only remember by actually typing it, over and over.

Operations Deployment, continued — kernel parameters, VMs, SELinux

# Kernel parameters — persistent and non-persistent
sysctl net.ipv4.ip_forward                 # read one live value
sysctl -w net.ipv4.ip_forward=1            # set it now — gone at reboot
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-mission.conf
sysctl --system                            # reload every persistent file

# Virtual machines (libvirt) and container engines
virsh list --all                           # every defined VM, running or not
virsh start mission-vm ; virsh shutdown mission-vm
podman ps -a ; podman inspect mission-agent --format '{{.State.Status}}'

# SELinux — mandatory access control (MAC)
getenforce                                 # Enforcing, Permissive, or Disabled
semanage fcontext -l | grep httpd_sys      # what context is expected where
restorecon -Rv /srv/www                    # fix a mislabeled tree
setsebool -P httpd_can_network_connect on  # a documented, persistent policy toggle

Networking — 25% of the paper, and most of the 3am pages

ip -br addr ; ip route                # modern replacement for ifconfig/route
ss -ltnp                              # who is listening, and which process owns it
resolvectl status                     # what resolver is this host ACTUALLY using?
nft list ruleset                      # nftables — the modern packet filter, not raw iptables
timedatectl status                    # clock skew breaks TLS handshakes and cluster health
ssh -F /dev/null user@host            # a client config sanity check, ignoring your own dotfile

Storage — 20%

lsblk -f ; df -hT ; findmnt /var/lib/containers
du -xhd1 /var | sort -h | tail        # who ate the disk? (images and journals, usually)
pvs ; vgs ; lvs                       # LVM, top to bottom
lvextend -r -L +10G /dev/vg0/var      # grow the LV and its filesystem in one step
mkswap /swapfile && swapon /swapfile  # swap space, configured on demand

Users and Groups — 10%

useradd -m -G mission -s /bin/bash dot
getfacl /srv/mission
setfacl -m u:dot:rx /srv/mission      # finer-grained than owner/group/other
id dot ; groups dot
ulimit -Sn                            # a resource limit, shell-scoped

Exam logistics — and the retired LFCE

☺ Like you're 10: Two hours at a real terminal, someone watching over video, a real machine to configure — and there used to be a "level two" version of this badge, but it doesn't exist anymore.

LFCS is performance-based, not multiple-choice: 17–20 real tasks, solved on a live terminal, graded on the final state of the machine — the same family of exam as CKA, not the knowledge-based format used by the other eight badges on this ladder. There is no formal prerequisite: nothing gates it, and gating aside, it is one of only two exams on the whole sixteen-exam ladder built this way, alongside CKA and the hands-on half of ICA.

↗ Official LFCS page — Linux Foundation ◆ Candidate handbook ◆ LFCE retirement notice

How to prepare, and what comes next

☺ Like you're 10: Learn the two domains worth half the test first, then drill the parts that only stick from typing them yourself, over and over, until your hands remember.

Start with the LFCS study plan, which maps every domain above to a pacing schedule built around a live terminal rather than flashcards, then work through the practice task bank and three timed papers — Mock Exam · Set 1, Set 2 and Set 3. For the conceptual foundation underneath this whole page, read Linux Fundamentals for Platform Engineers, and go deeper on the two tools this page leans on hardest in systemd & journald and LVM & Linux Storage Tools. For hands-on practice tracing exactly the failure this page walked through, run the broken cgroup-limit drill.

If you want the fuller comparison against a platform engineer's actual daily use of this material — including an honest verdict on when to skip the exam entirely — the deeper cross-reference lives on Platform Engineering's own LFCS page. And because this course assumes the five-exam Kubernetes core rather than re-teaching it, if Pod, Deployment and basic cluster fluency aren't solid yet, that foundation belongs before this page, not after it — see What Is Kubestronaut? and The Kubernetes Baseline You Need.