CELE common mistakes
CELE · Understand the traps and how to avoid them.
When asked where a configuration file lives or which directory holds a given type of data, the candidate guesses a path from memory instead of applying the FHS layout rules (for example placing variable data under /usr, or assuming a user's home is under /home when it was created elsewhere).
Candidates learn a handful of paths by rote (e.g. /etc/passwd, /var/log) but never internalise the Filesystem Hierarchy Standard categories - static vs. variable, shareable vs. unshareable, local vs. distribution-supplied - so unfamiliar paths get guessed rather than derived.
What to do instead
Memorise the FHS category grid and practise deriving paths from it: /etc for host-specific static config, /var for variable data (logs, spools, databases), /usr for shareable read-only distribution content, /opt for add-on packages, /srv for service data, /run for volatile runtime state, /tmp for world-writable scratch. For any question, first classify the data by those axes, then pick the directory.
When a command fails with 'Permission denied', the candidate immediately reaches for sudo or chmod 777 rather than reading the permission triplet and diagnosing whether the problem is ownership, mode bits, a missing execute bit on a parent directory, or an ACL.
Candidates memorise the octal table (644, 755, 777) but never practise reading a real ls -l line left to right - file type, owner/group/other triplets, then owner and group names - so the diagnostic step collapses into 'add permissions until it works'.
What to do instead
Drill the reading order: identify file type character, split mode into owner/group/other, then compare against the acting user and their group memberships (id). Remember that traverse permission on every parent directory is required to reach a file, and that the execute bit means something different on files (run) vs. directories (traverse). Prefer chown/chmod with the minimum change and verify with ls -l and namei -l <path>.
The candidate treats a process as a single unit and forgets that a shell pipeline creates several processes, so they mis-answer questions about which PID receives a signal, what `kill` on a pipeline job does, or why SIGTERM to a shell does not stop the child.
Process questions are studied as vocabulary (PID, PPID, zombie, orphan) without hands-on tracing, so the candidate never sees the process tree that a pipeline or a background job actually produces.
What to do instead
Practise with ps -ef --forest, pgrep -a, pstree -p, and jobs -l, and run pipelines in the background to observe that each stage is a separate PID under a subshell. Learn that signals go to a single PID unless you signal the process group, that SIGTERM is catchable while SIGKILL is not, and that a zombie is a reaped-but-uncollected exit status, not a running process.
On networking items, the candidate confuses the roles of IP address, netmask/prefix, default gateway, and DNS resolver, and answers 'cannot reach the internet' questions by changing the wrong layer (e.g. editing DNS when the fault is a missing default route).
These four settings are learned as a checklist copied from an installer screen rather than as separate functions, so the candidate cannot reason about which one explains a given symptom.
What to do instead
Anchor each setting to its job: address+prefix define local subnet membership, the gateway is the next hop for off-subnet traffic, DNS maps names to addresses. Then practise the layered diagnostic order - link (ip link), address/route (ip addr, ip route), name resolution (getent hosts, resolver config in /etc/resolv.conf or the local resolver service), then application. Test reachability by IP before testing by name to separate routing faults from DNS faults.
When asked to make a change persistent, the candidate edits a runtime setting (starting a service, adding a route, setting a hostname, mounting a filesystem) and stops there, without identifying the configuration file or unit that will restore it after reboot.
Interactive commands give immediate feedback and appear to work, so the candidate never builds the habit of asking 'what reads this at boot?' - a gap that shows up on every persistence question across services, networking, and storage.
What to do instead
For every runtime change, state the persistent counterpart explicitly: systemctl enable alongside start, a unit file or drop-in under /etc/systemd/system for service overrides, /etc/fstab for mounts, the network manager's own config for addresses, hostnamectl set-hostname for the hostname. Practise the pattern 'apply now, then write the file that survives reboot, then verify with a reload or a documented check'.
The candidate runs package operations without knowing which package manager and repository model the distribution uses, mixing commands from different families (e.g. invoking a low-level package tool directly when the task expects the dependency-resolving front end, or assuming a repository file location from the wrong distribution).
Package management is often learned on one distribution and then generalised, so the candidate cannot map a task ('install, query which package owns a file, list available versions, hold a package back') onto the correct tool for the distribution named in the question.
What to do instead
Build a two-column map: distribution family on one side, and on the other the front-end install/remove/upgrade command, the query commands for file ownership and package contents, the repository configuration location, and the cache-refresh step. Learn the distinction between the dependency-resolving front end and the lower-level package tool, and note that a cache refresh is usually required before install or search.
In shell scripting items, the candidate writes pipelines and redirections that work interactively but fail in a script - quoting variables loosely, ignoring exit status, or assuming a relative path resolves from the script's own directory.
Interactive shells hide these faults because the candidate is watching output and correcting by hand; scripts run unattended and from arbitrary working directories, so the unquoted expansion, the unchecked failure, and the relative path all surface at once.
What to do instead
Adopt a fixed script skeleton: a shebang line, set -euo pipefail (understanding what each part does), quoted expansions "$var", if ! cmd; then or explicit $? checks, and absolute paths derived from a variable rather than the current directory. Test scripts by running them from a different directory and with arguments containing spaces.
The candidate answers user and group questions by editing /etc/passwd or /etc/group directly, or creates accounts without setting password aging, shell, home directory, or supplementary groups - and cannot explain where the shadowed password hash actually lives.
The account database files are memorable and easy to quote, so the candidate treats them as the interface rather than as files managed by dedicated tools, and skips the secondary questions (aging, shell, group membership) that the exam asks alongside account creation.
What to do instead
Use and memorise the tool layer: useradd/usermod/userdel, groupadd/gpasswd, passwd -S/chage -l for aging, id and groups to verify membership. Know that password hashes live in the shadow file readable only by privileged users, that supplementary group membership is stored in the group database, and that direct edits bypass validation and locking.
The candidate cannot distinguish kernel, init/systemd, and userland responsibilities, so questions about boot order, where a service's configuration is read, or what a given log entry implies are answered by attributing behaviour to the wrong layer.
Architecture is skimmed as a diagram (kernel, shell, utilities) without connecting it to observable behaviour - boot sequence, unit ordering, log sources - so the model stays abstract and cannot be applied.
What to do instead
Trace one boot end to end: firmware, bootloader, kernel plus initramfs, then the init system starting units in dependency order. For each layer, note what it owns and where its evidence appears (kernel messages vs. service manager journal vs. application logs). Practise reading systemctl status, unit dependencies, and the journal with time and unit filters to confirm which layer produced a message.
On security and administration items, the candidate answers with a plausible-sounding but over-broad measure (disabling a firewall to fix connectivity, granting broad sudo rights to solve a permission problem, or setting world-writable permissions) instead of the least-privilege action the question is testing.
Under time pressure the candidate optimises for 'makes the symptom disappear' rather than for the security property being examined, because least privilege and its supporting tools (sudoers scoping, key-based SSH authentication, file modes on sensitive files) were reviewed as definitions rather than as decision rules.
What to do instead
For every administration question, apply a three-part check before answering: what is the minimum privilege needed, who should hold it, and how is the change audited or reverted? Learn the concrete forms - scoped sudoers rules instead of full sudo, key-based SSH with password authentication disabled and correct permissions on the key and .ssh directory, restrictive modes on credential files, and firewall rules that open a specific port rather than the whole interface.