LFCS: essential skills

This page lists the exhaustive official competencies of the LFCS certification, as described in the blueprint published by the Linux Foundation. For each domain, it translates these competencies into concrete know-how to demonstrate in a lab.

It is not a closed list of commands to memorise: the Linux Foundation publishes a competency framework, not a checklist of imposed tools. The goal is to help you identify what you must be able to do on exam day.

One point deserves to be cleared up before going further, because it skews many candidates' preparation. The Essential Commands domain no longer covers file navigation or classic Unix permissions. It now covers basic Git operations, creating and troubleshooting services, performance monitoring, application constraints, disk space diagnosis and SSL/TLS certificates.

Navigation, permissions and text handling remain implicit prerequisites: you are expected to master them, but they are no longer stated objectives. Revising those actions therefore scores no point on the 20% this domain weighs.

Check the blueprint before registering

Domains and their weighting change: training.linuxfoundation.org/certification/lfcs.

What you will learn

• Place the five official domains and their weight in the score
• Translate each published competency into concrete actions to demonstrate in a lab
• Avoid the frequent pitfalls, domain by domain
• Spot the underestimated skills that make the difference

The 5 official domains

The percentages below are not decorative: they determine how many tasks from each domain come up on the day. Out of the 17 to 20 tasks of the exam, a domain at 25% represents four to five, a domain at 10% one or two. Read this table as a revision budget: the time spent on each block should follow roughly the same split as the weights shown.

Domain	Weight
Operations and Deployment	25%
Networking	25%
Storage	20%
Essential Commands	20%
Users and Groups	10%

Swipe to see more

How to read this page

For each domain, the "Official competencies" section repeats the titles of the Linux Foundation blueprint. The "What it means in practice" section is a teaching translation: it describes what a candidate must be able to do in practice, without imposing specific tools.

---

Operations and Deployment (25%)

This domain covers day-to-day system management: processes, services, scheduling, packages, recovery after an incident, virtualisation, containers and mandatory access control.

Official competencies

The eight titles below translate the objectives published by the Linux Foundation. They are worded as action verbs because the exam grades a system state obtained, never a method. Spot the double verbs such as "manage and troubleshoot": they announce tasks where the service is already broken at the start and where your first action will be to read a log, not to write a configuration.

1. Configure kernel parameters, persistent and non-persistent
2. Diagnose, identify, manage and troubleshoot processes and services
3. Manage or schedule jobs for executing commands
4. Search for, install, validate and maintain software packages or repositories
5. Recover a system from hardware, OS or filesystem failures
6. Manage virtual machines with libvirt
7. Configure a container engine, create and manage containers
8. Create and enforce mandatory access control with SELinux

What it means in practice

Use this breakdown as a self-assessment grid rather than as a course. For each bullet, ask yourself a single question: could you carry it out without documentation, then check the result with a verification command? A skill you understand without ever having typed it counts as a gap: the performance-based format only grades the state of the machine at the end of the allotted time.

Kernel parameters:

• Be able to change a kernel parameter temporarily and persistently
• Know where to put a persistent configuration and how to apply it without a reboot
• Examples of frequent parameters: IP forwarding, network buffer sizes, system limits

Processes and services:

• Know how to list processes, identify the one using the most CPU or memory
• Stop a process cleanly, then forcibly if needed
• Manage a shell's background jobs
• Change the priority of a running process
• Start, stop, enable a service, understand the difference between an active service and one enabled at boot
• Diagnose a service that will not start: read the logs, identify the cause, fix and check

Scheduling:

• Create a recurring task that runs on a schedule
• Create a one-off deferred task
• Know the two main scheduling mechanisms on Linux (cron and systemd timers)
• Know how to check that a scheduled task is in place

Packages and repositories:

• Install, remove and search for packages, on the Debian and RHEL families
• Identify which package provides a given file or command
• Manage a package repository: add, disable, check

System recovery:

• Reach rescue or emergency mode through the boot loader
• Repair a corrupted (unmounted) file system
• Regenerate the boot loader configuration
• Investigate the logs of the previous boot

libvirt virtualisation:

• List VMs, start them, stop them cleanly, force them off
• Create a VM from a definition file
• Configure a VM to start automatically
• Access a VM's console
• Clone an existing VM

Containers:

• Run a container in the background, expose a port
• Inspect a container, run a command inside it
• Stop and remove a container
• Generate a system service from an existing container
• The tool depends on the distribution, the skills are the same whatever the engine

SELinux:

• Check the current mode (enforcing, permissive, disabled)
• Display and change a file's SELinux context
• Apply a permanent context for a custom directory
• Enable an SELinux boolean persistently
• Allow a non-standard port for a service
• Diagnose an SELinux denial: read the audit logs, identify the cause, apply the fix

Frequent pitfalls

These four mistakes share the same failure mode: the command returns code 0, no output signals an anomaly, and the task is still counted wrong. It is what costs the most in a hands-on exam, since nothing alerts you. The defence is mechanical: after each change, reread the persistent state written to disk, never only the current state in memory.

• Changing a kernel parameter or an SELinux boolean without making it persistent: the effect is lost at reboot
• Disabling SELinux instead of managing it: the LFCS requires working in enforcing mode
• Using chcon alone without semanage fcontext: the context will be overwritten at the next relabel
• Forgetting daemon-reload after changing a systemd unit

---

Networking (25%)

This domain covers the whole network stack: addressing, name resolution, time synchronisation, monitoring, SSH server and client, filtering/NAT, routing, interface aggregation and reverse proxy.

Official competencies

Networking weighs as much as operations, and its scope is the widest of the blueprint: it goes from addressing an interface all the way to setting up a reverse proxy. Points 5 to 8 are the ones most candidates discover on exam day, because filtering, NAT, bonding and load balancing fall outside the scope of a workstation or a classic application server.

1. Configure IPv4 and IPv6 as well as hostname resolution
2. Set and synchronise system time using time servers
3. Monitor and troubleshoot networking
4. Configure the OpenSSH server and client
5. Configure packet filtering, port redirection and NAT
6. Configure static routing
7. Configure bridge and bonding devices
8. Implement reverse proxies and load balancers

What it means in practice

Most of the blocks below need two machines to be worked on seriously, otherwise you will never see fail what must fail. A filtering rule is not tested from the machine it protects, and a static route only makes sense towards a destination otherwise unreachable. Set up a two-VM lab before tackling this list, otherwise the verification will stay theoretical.

Addressing and resolution:

• Display and change an interface's IP configuration, IPv4 and IPv6
• Make a network configuration persistent with the distribution's mechanism
• Change the hostname persistently
• Configure local name resolution and DNS servers

Time synchronisation:

• Check the current NTP synchronisation
• Change the reference NTP servers and restart the service
• Make sure synchronisation is active and persistent

Network monitoring:

• Test basic connectivity (ICMP, traceroute)
• Identify listening ports and the associated processes
• Resolve a domain name and diagnose a DNS problem
• Capture network traffic for analysis
• Test an HTTP/HTTPS connection

OpenSSH server and client:

• Generate a key pair and deploy the public key to a remote server
• Configure the SSH server: change the port, disable password authentication, forbid direct root login
• Apply the changes without cutting active sessions
• Configure connection shortcuts on the client side

Filtering, NAT, port redirection:

• Open a specific port for a service, permanently
• Apply the rules, know that a rule not applied is not active
• Configure NAT masquerade (in French) to let an internal network get out
• Configure a port redirection (port forwarding)
• The blueprint does not prescribe a specific firewall tool, the skills are the same whatever the tool

Static routing:

• Add a temporary static route
• Make a static route persistent
• Check the routing table

Bridge and bonding:

• Create a Linux bridge and attach interfaces to it
• Create a bonding interface with an aggregation mode (active-backup, balance-rr…)
• Check that the aggregation works

Reverse proxy and load balancer:

• Set up a reverse proxy that forwards traffic to a backend
• Configure load balancing between several backends
• Check the configuration syntax and apply without interruption

Frequent pitfalls

Networking adds a risk the other domains do not have: a wrong configuration can cut you off from the machine while you work. Get into the habit of keeping a local console or an already open session before touching an interface or a filtering rule. In substance, the points below all come down to confusing a change applied in memory with a change saved in a file.

• Configuring an IP address or a firewall without persistence: everything disappears at reboot
• Forgetting to reload the firewall rules after creating them in permanent mode
• Centring your preparation on nmcli or ufw only, without mastering ip as the common denominator
• Ignoring the SSH server configuration: the blueprint explicitly covers the server, not only the client
• Not practising bridge/bonding and reverse proxy: these topics are in the blueprint and often neglected

---

Storage (20%)

This domain covers full storage management: logical volumes, local and remote file systems, persistent mounts, swap, automatic mounts and performance.

Official competencies

Storage is the most mechanical domain of the blueprint: tasks there are long but rarely ambiguous, because they almost always follow the same chain of operations (spot the device, partition, format, mount, persist). Two skills escape this logic and need a machine on the other side: remote file systems (point 4) and automounters (point 6).

1. Configure and manage LVM storage
2. Manage and configure the virtual file system
3. Create, manage and troubleshoot file systems
4. Use remote file systems and network block devices
5. Configure and manage swap
6. Configure automounters
7. Monitor storage performance

What it means in practice

The thread running through this whole domain is the order of operations. A successful storage task chains creation, formatting, mounting then persistence, and skipping the last step is enough to lose all the points. Note along the way the verification commands that come up everywhere, lsblk, blkid and findmnt: they are your only proof that the requested state is really reached.

LVM:

• Create a Physical Volume, a Volume Group and a Logical Volume
• Extend a Volume Group by adding a disk
• Extend a Logical Volume and resize the file system accordingly (ext4 and xfs)
• Delete a Logical Volume
• Know that resize2fs works offline or online, whereas xfs_growfs only works on a mounted FS

Virtual file system and file systems:

• Identify the available disks and partitions
• Create and format partitions (ext4, xfs, vfat)
• Diagnose a corrupted file system and repair it (unmounted)
• Find the UUID of a block device

Persistent mounts:

• Mount a file system temporarily
• Make a mount persistent through /etc/fstab, always with UUID, never with /dev/sdX
• Check the consistency of /etc/fstab and test without a reboot

Remote file systems and network block devices:

• Mount an NFS share persistently; under systemd, the file system type is enough to classify the mount as a network one, _netdev only forces this detection
• Mount a CIFS share with a separate credentials file
• Discover and connect to an iSCSI target, and there _netdev becomes essential: a network block device is not recognised as network from its file system type

Swap:

• Create a swap partition or a swap file
• Enable swap and make it persistent

Automounters:

• Configure autofs to mount a share on demand
• Understand the relationship between /etc/auto.master and the map files
• Check that dynamic mounting works

Storage performance:

• Identify which disk or process causes excessive I/O
• Measure a disk's raw throughput
• Monitor space usage in real time

Quotas are not in the current LFCS blueprint

Disk quotas are among the useful tools in Linux administration, but they do not appear in the LFCS domains and competencies published today. Do not prioritise them in your LFCS preparation.

Frequent pitfalls

Three of these four mistakes only show up at reboot, so far too late in a timed exam. Make detection immediate: after any edit of /etc/fstab, chain findmnt --verify then mount -a. The first checks the file's consistency without mounting anything, the second replays the missing entries and fails loudly on an invalid entry, which saves you from discovering the problem after a reboot.

• Using /dev/sdX instead of the UUID in /etc/fstab: device names can change
• Forgetting _netdev on a mount sitting on top of a network block device (iSCSI, NBD): systemd cannot guess from the file system type that it depends on the network, and the mount fails at boot
• Extending an LV without resizing the file system: the extra space stays invisible
• Not practising autofs: dynamic mounting is specific and only mastered through practice

---

Essential Commands (20%)

This domain covers cross-cutting skills that are not limited to file navigation. It assesses the ability to use Git, to create and troubleshoot services, to monitor performance, to identify an application's constraints, to diagnose disk space problems and to work with SSL/TLS certificates.

Official competencies

The name of the domain is misleading: "Essential Commands" no longer refers to the basic shell commands but to a set of cross-cutting skills that the Linux Foundation did not want to attach to the other four blocks. Git and SSL/TLS certificates sit alongside performance diagnosis and disk space. Treat each of the six points as a standalone mini-domain; they have no tool in common.

1. Basic Git Operations
2. Create, configure and troubleshoot services
3. Monitor and troubleshoot system performance and services
4. Determine the constraints specific to an application or service
5. Troubleshoot disk space issues
6. Work with SSL certificates

What it means in practice

The blocks of this domain are worked on a single machine with no particular hardware, which makes them the best starting point if you are short of time or lab. Prioritise in this order: service diagnosis, disk space, certificates, then Git. The first three are those where a misunderstood task costs you several minutes of blind searching, whereas the Git operations asked for remain deliberately basic.

Git:

• Initialise a local repository, clone a remote repository
• Stage files, create a commit with a message, read the history
• Create a branch, switch to it, merge
• Set aside work in progress (stash)
• Manage a remote repository: add, push, pull
• Configure the Git identity (name, email), often needed before the first commit

Services:

• Write a minimal working systemd unit file
• Diagnose a service in the failed state: read the logs, identify the error, fix, reload and check
• Apply a unit change without restarting the whole daemon

Performance and monitoring:

• Identify which process uses the most CPU, memory or I/O
• Monitor the load average and available memory
• Use continuous monitoring tools (refresh at an interval)
• Read a historical performance report (if sysstat is available)

Application constraints:

• Display the effective limits of the current shell or of a specific process
• Identify the limits imposed on a systemd service
• Find the files opened by a process
• Change a kernel parameter that constrains a service's behaviour

Disk space:

• Identify which file system is full and which directory is the cause
• Find the large files of a file system
• Detect files deleted but still open by a process, a frequent cause of an invisible "full disk"
• Check the available inodes (a file system can be "full" with free space if the inodes are exhausted)
• Clean up system logs that have grown too large

SSL/TLS certificates:

• Generate a private key and a certificate signing request (CSR)
• Create a self-signed certificate
• Inspect an existing certificate: validity dates, subject, issuer
• Test a TLS connection to a remote server
• Check a certificate's chain of trust
• Install a certificate authority on the system; the procedure differs by distribution

Frequent pitfalls

The main pitfall of this domain is a misunderstanding about its name, and it leads to not revising it at all. The four following points all stem from this initial dead end: a candidate who reads "essential commands" as "ls, cd, grep" arrives at the exam without having opened openssl or diagnosed a service in the failed state, although this block weighs 20% of the score.

• Treating this domain as "the basic Linux commands": that is no longer the case since the blueprint overhaul
• Neglecting Git: it is an official competency in its own right
• Not knowing how to diagnose a failed service beyond reading status
• Ignoring lsof +L1 for full-disk problems with no visible files
• Not knowing how to handle SSL certificates: this topic is explicitly in the blueprint

---

Users and Groups (10%)

It is the least weighted domain, but it contains precise skills that cannot be improvised on the day, notably ACLs, environment profiles and LDAP integration.

Official competencies

These five titles range from the very common to the very rarely practised, and the gap is stark: creating a local account is a daily action, plugging the system into an LDAP directory is not. The weight of 10% must not mislead you about the effort required: points 4 and 5, ACLs and LDAP, alone demand more preparation than the first three combined.

1. Create and manage local user and group accounts
2. Manage environment profiles, personal and system-wide
3. Configure user resource limits
4. Configure and manage ACLs
5. Configure the system to use LDAP user and group accounts

What it means in practice

Two skills in this list are verified otherwise than by reading a configuration file. For ACLs, the proof is getfacl on the target, not the output of ls -l. For LDAP, the proof is getent passwd <user> returning a line, not the fact that the directory service is running. Spot these verification commands while reading the bullets; they make the difference between a task believed done and a task really done.

Local accounts and groups:

• Create a user with precise parameters: home, shell, UID, primary group
• Add a user to a secondary group without losing their existing groups
• Lock and unlock an account
• Configure password expiry and account expiry
• Create groups with a specific GID
• Delegate rights through sudo with least privilege, files in /etc/sudoers.d/ (a useful action, but sudo is not named in the blueprint)

Environment profiles:

• Understand the difference between /etc/profile, /etc/profile.d/, ~/.bash_profile, ~/.bashrc and /etc/environment
• Know where to add an environment variable so that it is available to all users or to just one
• Know how to apply a profile change without logging out

Resource limits:

• Display the current limits of a shell or a process
• Configure permanent limits (open files, number of processes…)
• Identify and change the limits of a systemd service

ACL:

• Add a permission for a specific user or group on a file or directory
• Set default ACLs so that new files inherit them
• Remove targeted ACLs or reset all ACLs
• Check that a file system supports ACLs
• Recognise the presence of ACLs in the output of ls -l (the + indicator)

LDAP:

• Configure the system to resolve user and group accounts from an LDAP server
• Check that the LDAP user is resolved locally
• Understand the role of nsswitch.conf in the resolution order
• Make sure the authentication service is enabled and persistent
• Configure automatic home directory creation at first login
• The tools differ by distribution, the underlying skills are identical

LDAP is in the blueprint, do not neglect it

Integrating LDAP accounts appears explicitly in the Users and Groups domain. This topic is frequently ignored in revision because it requires a working LDAP server to practise. Set up an LDAP lab or use the companion repository.

Frequent pitfalls

The first mistake in this list is destructive and silent: it removes groups from an account without the slightest warning, and you only notice at the next access refusal. Get into the habit of recording the current groups with id <user> before any change, then comparing afterwards. The other three points are omissions rather than destructions, but they cost the same points.

• Using usermod -G instead of usermod -aG: without -a, the existing secondary groups are overwritten
• Not understanding the difference between login and non-login profile files
• Forgetting that ACLs need suitable file system support
• Ignoring LDAP in the preparation: it is an official topic

---

Often underestimated skills

These topics are in the blueprint but frequently missing from revision. Each of them can represent one or more tasks on the day.

Skill	Domain	Why it is underestimated
SELinux	Operations	Many disable it day to day, but the LFCS requires managing it in enforcing mode
libvirt / KVM	Operations	Rarely practised outside a dedicated lab
Containers	Operations	The engine depends on the distro, you must master the concept, not just one tool
OpenSSH server	Networking	Candidates prepare the client, not the server configuration
NAT / port redirection	Networking	More complex than opening a simple port
Bridge / bonding	Networking	Rarely used day to day, but in the blueprint
Automounters	Storage	autofs is only mastered through practice
LDAP	Users	Requires an LDAP server to practise
Reverse proxy / load balancer	Networking	Often seen as "outside sysadmin scope"
SSL/TLS	Essential commands	Handling certificates takes practice
NTP synchronisation	Networking	Often neglected because "it works on its own"
Persistent kernel parameters	Operations	Knowing how to change sysctl is not enough, the change must be made permanent

Swipe to see more

---

Preparation reflexes

These principles apply across all the domains.

Always tell temporary from persistent:

Each change that must survive a reboot requires an explicit persistence action. If you do not know how to make a change permanent, you have not yet mastered the skill.

Always check the result after a change:

Configuring is not enough. After each action, check the state with a verification command: systemctl status, ip addr, findmnt, ss -tulpn, getenforce, firewall-cmd --list-all…

Know how to diagnose, not just configure:

The blueprint explicitly asks you to troubleshoot, not just to configure. You must know how to identify the cause of a problem, read logs, interpret an error message and fix it.

Do not revise only your daily routine:

If your environment is Debian-centred, you have probably never touched SELinux, firewalld or authselect. If your environment is RHEL-centred, you may never have configured netplan or ufw. The blueprint is vendor-neutral: practise the topics outside your comfort zone.

Practise the rare topics of the blueprint:

libvirt, containers, bridge/bonding, autofs, LDAP and reverse proxy are part of the exam. These are skills mastered in a lab, not by rereading a documentation page.

Use the allowed resources:

During the exam, you have access to man, --help, info and /usr/share/doc. Learn to consult them efficiently: quickly finding the right option in a man page saves precious time.

---

Key points

• The LFCS assesses skills, not the memorisation of commands; the blueprint describes what you must be able to do.
• The Networking and Operations domains make up 50% of the score; they are the blocks to master first.
• Each change must be checked: configure → check → persist → check after reboot.
• The blueprint is vendor-neutral: the exam is no longer tied to a particular distribution, but you must know the mechanisms common to all of them.
• The often neglected topics are also the most discriminating: SELinux, libvirt, containers, reverse proxy, LDAP, bridge/bonding.
• Disk quotas are not in the current LFCS blueprint.
• The Linux prerequisites (navigation, permissions, editing with vi) are implicit but essential.
• Practice in a real lab is irreplaceable; rereading a commands page is not enough.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →