CompTIA Linux+ common mistakes
CompTIA Linux+ · Understand the traps and how to avoid them.
Creating a filesystem on the whole disk instead of the partition just created, or running mkfs immediately after fdisk/parted without refreshing the kernel's partition table; then adding the new filesystem to /etc/fstab by device name rather than UUID and never testing the entry.
Candidates memorize the individual commands but not the ordered workflow, so they skip the step where the kernel re-reads the partition table and they leave a mistyped fstab entry that only fails at the next reboot.
What to do instead
Drill the full sequence on a spare disk: fdisk/parted -> partprobe (or udevadm settle) -> verify with lsblk -> mkfs.xfs/mkfs.ext4 on the partition node -> blkid for the UUID -> edit /etc/fstab -> run 'mount -a' and 'systemctl daemon-reload' to prove the entry works before rebooting.
Answering package questions with tools from the wrong distribution family, e.g. recommending 'apt-get install' on a RHEL host, or being unable to say which package owns /usr/bin/ssh or which command finds a package that provides a missing binary.
Most study material is written for one distribution, so candidates learn a single toolchain and freeze when the question stem names dnf, rpm, zypper, apt, or dpkg.
What to do instead
Build a two-column cross-reference (Debian: apt/dpkg/apt-file/dpkg -S/dpkg -L; RHEL: dnf/rpm/dnf provides/rpm -qf/rpm -ql) and practice each command in both a Debian and a RHEL-family VM, including where repositories and GPG keys are configured (/etc/apt/sources.list.d vs /etc/yum.repos.d).
Managing services with SysV habits ('service ssh restart', chkconfig, update-rc.d) on a systemd host, using 'systemctl start' when the requirement is that the service survive a reboot, and editing a unit file without reloading the manager.
Older training material and muscle memory from legacy distros carry over, and start/enable are easy to conflate when reading quickly.
What to do instead
Standardize on systemctl verbs and practice the distinctions: start vs enable vs enable --now, disable vs mask, 'systemctl edit' for drop-ins, 'systemctl daemon-reload' after any unit change, and 'systemctl status' / 'journalctl -u ' as the verification step.
Assuming useradd always creates a home directory, using 'usermod -G wheel bob' and silently stripping bob's other supplementary groups, and being unable to read or set shadow fields (last change, expiry) with chage.
Defaults differ by distribution (Debian-family creates the home directory by default, RHEL-family does not without -m), and -G versus -aG looks like a trivial flag difference rather than a destructive one.
What to do instead
Always use 'useradd -m -s /bin/bash' and 'usermod -aG group user'; verify with 'id user' and 'getent group'. Practice chage -l/-M/-E, passwd -e for forced reset, /etc/skel for default dotfiles, and 'userdel -r' so account-removal questions are handled completely.
Editing /etc/sudoers directly with vi, and changing sshd_config (e.g. PermitRootLogin, PasswordAuthentication, Port) then restarting without running a syntax check, without noticing Include drop-ins in sshd_config.d, or without keeping an existing session open.
Both files are plain text that 'looks editable', and sshd uses the first value it obtains, so a drop-in file included at the top quietly overrides the lines the candidate edited lower in the main file.
What to do instead
Use visudo (and visudo -c) for sudoers; for SSH run 'sshd -t' before reloading, remember that /etc/ssh/sshd_config.d/*.conf is included first and wins, and always test from a second terminal while keeping the original session open.
Fixing a denied access by running 'chmod 777', or relabelling with chcon and expecting it to persist, when the problem is an SELinux/AppArmor policy or file-context mismatch.
SELinux is usually disabled or permissive on candidates' lab boxes, so denials never appear during practice and the standard DAC reflexes take over on exam day.
What to do instead
Learn the enforcing toolkit end to end: getenforce/sestatus, 'ls -Z', ausearch -m avc -ts recent and sealert to read the denial, 'semanage fcontext -a -t httpd_sys_content_t' followed by 'restorecon -Rv' (chcon is temporary because a relabel reverts it), setsebool -P for booleans, and permissive-vs-disabled requiring a reboot and a relabel.
Writing scripts with unquoted variables and no error handling, then being unable to explain the exit status; or writing a cron entry with a bare command name, relative paths, and an unescaped % in the command.
Scripts work in the candidate's interactive shell because PATH and quoting bugs only surface with spaces, globs, or a failure mid-run; cron runs with a minimal environment and its own parsing rules.
What to do instead
Start scripts with '#!/bin/bash' and 'set -euo pipefail', quote "$var", check $? deliberately, and test with shellcheck. For scheduling, use absolute paths, redirect output, escape % as %, and know the systemd-timer equivalent (OnCalendar) plus where cron logs go.
Conflating related automation and container concepts: treating an Ansible 'shell' task as idempotent, mixing up an image with a running container, or confusing Dockerfile ENTRYPOINT with CMD; also freezing on basic git operations.
These are concept questions rather than command questions, and candidates who have only run a few docker commands lack the mental model the exam probes.
What to do instead
Practice small, complete loops: write and rerun a playbook with a module task to see idempotence, build an image and run/exec/stop/rm a container with podman rootless, and state aloud the difference between ENTRYPOINT (fixed executable) and CMD (default arguments). Add the clone/commit/push/branch workflow.
Jumping straight to a fix instead of following a diagnostic sequence, and reaching for the wrong tool: netstat instead of ss, 'du' to explain a full filesystem that 'df' reports as full, or reading only /var/log/messages instead of journalctl for a failed unit.
Exam items are written as symptoms with several plausible causes, and candidates answer from pattern recognition rather than gathering evidence first.
What to do instead
Rehearse a fixed loop on lab faults: reproduce, gather (journalctl -b -p err, dmesg, systemctl status, ss -tulpn, ip a, ping/traceroute/dig), form one hypothesis, test it, then verify. Memorize the classic mismatches: deleted-but-open files (lsof +L1) explain df vs du gaps, and 'free' available is not the same as free.
Being unable to recover a system that will not boot: not knowing how to reach a rescue/emergency target, reset a forgotten root password, or repair a broken GRUB configuration, and not verifying or documenting the change afterwards.
Boot repair is rarely practiced because it requires deliberately breaking a VM, so the candidate has read about rd.break or grub rescue but never executed it.
What to do instead
Break and fix your own VM: interrupt GRUB to edit the kernel line (rd.break or init=/bin/bash), remount /sysroot rw and chroot to reset the root password plus 'touch /.autorelabel', boot to rescue.target, and reinstall GRUB (grub2-install/update-grub). Finish every scenario by confirming the service or login works and recording what changed.