LFCE common mistakes
LFCE · Understand the traps and how to avoid them.
Editing /etc/network/interfaces or nmcli settings but never reloading them, then testing connectivity against the stale configuration still held in memory.
Candidates assume a config file change takes effect immediately, but on Debian systems the change only applies after ifup/ifdown or a systemctl restart networking, and on NetworkManager systems only after nmcli connection up or a reload. The old address or route keeps answering, so the candidate misdiagnoses the file they just edited as wrong.
What to do instead
After every change, explicitly apply and verify: run ip -br addr and ip route to confirm the live state matches the file, and use ifup/ifdown or nmcli connection up deliberately. Make 'change, apply, verify with ip/ss' a fixed three-step habit before drawing any conclusion.
Creating a filesystem or partition table on a device that already holds data, or running mkfs on the wrong disk, because the candidate identified the disk by letter (sdb, sdc) instead of by UUID, size, or serial.
Device letters shift between boots and after hotplug, and exam environments often attach several similar-sized virtual disks. Candidates under time pressure pick the disk that looks right in lsblk output and skip confirming identity, which destroys existing data and can make the task unrecoverable within the time limit.
What to do instead
Before any destructive operation, run lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID and blkid, and confirm the target by size and UUID. Prefer referencing devices by /dev/disk/by-uuid or /dev/disk/by-id in fstab. If the disk already has a filesystem, stop and re-read the task.
Adding an entry to /etc/fstab without testing it, or using a device name or missing option, then rebooting and dropping into emergency mode.
fstab is consumed early at boot, and any unparseable or unmountable entry blocks the boot into emergency shell. Candidates test mounts only with a manual mount command that bypasses fstab, so the error only surfaces after reboot, when the candidate has already lost access to fix it easily.
What to do instead
Always validate with mount -a immediately after editing fstab; it must complete silently. Use nofail for non-critical mounts, use UUIDs, and check option spelling. Confirm the mount survives with systemctl daemon-reload and a controlled reboot while you still have a console.
Configuring a service, starting it, and never checking that it is actually listening on the expected port and address, or that the firewall permits the traffic.
A service can start cleanly yet bind only to 127.0.0.1, fail to bind because another process holds the port, or be blocked by firewalld/nftables. Candidates see 'active (running)' in systemctl status and declare success without testing the actual network path the grader will use.
What to do instead
After starting, run ss -tlnp to confirm the listen address and port, then test from the client side with curl, nc, or a real client. Open the port explicitly with firewall-cmd --add-service or --add-port --permanent and reload. Verify with systemctl status, journalctl -u for errors, and an end-to-end connection.
Writing a firewall rule with --permanent only, or runtime only, and assuming it is in effect across both.
firewalld keeps runtime and permanent configurations separate; a --permanent rule is not active until reload, and a runtime rule vanishes on reload or reboot. Candidates add the rule they think is needed, test once, and either the test fails (runtime missing) or the rule disappears later (permanent missing).
What to do instead
Decide which layer you are changing and be explicit: use --permanent then firewall-cmd --reload, or add to runtime for immediate effect and also --permanent for persistence. Verify with firewall-cmd --list-all and --list-all --permanent, and confirm the rule survives a reload.
Troubleshooting by restarting services and rebooting before reading logs, losing the evidence of the original failure.
Restarting feels productive and often makes the symptom disappear temporarily, but it clears the process state and rotates the journal context that explained the fault. Candidates then cannot explain the root cause and the problem recurs during grading.
What to do instead
Read first: journalctl -u -b --no-pager, journalctl -xe, dmesg -T, and the service's own log file. Note timestamps and the last error before any restart. Only restart after you have captured the failing state, and reproduce deliberately if needed.
Writing a shell script or cron job that works interactively but fails when scheduled, because it relies on the interactive PATH, current working directory, or environment variables.
cron runs with a minimal environment and a different working directory, and systemd units have their own environment. Candidates test by running ./script.sh from their shell, where PATH and relative paths resolve, and never test under the conditions the scheduler actually uses.
What to do instead
Use absolute paths for commands and files, set PATH explicitly at the top of the script or in the unit, and test with env -i /bin/bash /path/script.sh to simulate the minimal environment. For cron, redirect output to a log and check it; for systemd, use systemctl status and journalctl to confirm the unit's environment.
Setting up SSH key authentication by copying the public key but leaving permissions or ownership wrong on ~/.ssh or authorized_keys, so authentication silently falls back to password or is refused.
sshd with StrictModes enabled refuses keys when the home directory, .ssh, or authorized_keys are group- or world-writable, or owned by another user. Candidates copy the key correctly and assume the mechanism is broken, rather than the permissions that guard it.
What to do instead
Set chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, chmod 700 or 750 the home directory, and ensure ownership matches the target user. Test with ssh -v to see which authentication method is actually attempted, and check /var/log/auth.log or journalctl -u ssh for permission warnings.
Configuring storage or networking changes that are correct now but not persistent, such as mount, ip addr add, or route commands run manually without a corresponding config file.
Imperative commands change only the running state. Candidates verify with the live command, see success, and move on, but the grader or a reboot resets the state and the change is gone. This is especially common with static routes and secondary addresses.
What to do instead
For every runtime change, ask where it is persisted: /etc/fstab for mounts, NetworkManager connection profiles or /etc/network/interfaces for addresses and routes, and systemd units for services. After writing the persistent config, reboot or restart the relevant service and re-verify the live state matches.
Ignoring SELinux or AppArmor contexts when a service fails to read a file or bind a port, and instead loosening file permissions or disabling the service.
On enforcing systems, a correctly permissioned file can still be denied because of its SELinux type, and a non-standard port needs an explicit port label. Candidates see 'permission denied' and chmod 777 the path, which does not change the context and masks the real cause.
What to do instead
Check the audit trail with ausearch -m avc -ts recent or journalctl for AVC denials, inspect contexts with ls -Z and ps -Z, restore defaults with restorecon -Rv on the path, and label ports with semanage port -a. On AppArmor, check aa-status and dmesg for denials. Fix the label rather than disabling enforcement.