Home / networking / CompTIA Linux+ / Cheat Sheet
CompTIA Linux+

Linux+ Cheat Sheet

Linux+ Tests Applied Linux Administration — Command Syntax and Troubleshooting Under Pressure

The exam tests whether you can administer Linux systems in production: file permissions, process management, networking, scripting, and security hardening.

Check Your Readiness →
Among the harder certs
Avg: Approximately 63–68%
Pass: 750 / 1000
Most candidates understand CompTIA Linux+ concepts — and still fail. This exam tests how you apply knowledge under pressure.

Linux+ Administration Domain Framework

Linux+ (XK0-005) has five domains. Questions test knowledge of specific commands, file system concepts, and troubleshooting approaches. Know the key commands for each domain cold — exam scenarios require precise command and option knowledge.

  1. 01
    System Management — Installation, boot process, package management, systemd
  2. 02
    Security — File permissions, SELinux/AppArmor, PAM, firewall (firewalld, iptables)
  3. 03
    Scripting, Containers & Automation — Bash scripting, Git, containers (Docker)
  4. 04
    Troubleshooting — Diagnosis methodology for Linux systems
  5. 05
    Networking — Configuration, DNS, DHCP, SSH, network troubleshooting

Wrong instinct vs correct approach

A service is not starting after system reboot
✕ Wrong instinct

Manually start the service each time

✓ Correct approach

Use systemctl enable to create the symlink for automatic start at boot — systemctl start only starts it for the current session; enable persists across reboots

A user reports permission denied when accessing a file they should have access to
✕ Wrong instinct

Use chmod 777 to open all permissions on the file

✓ Correct approach

Diagnose the actual permission issue: check file permissions (ls -l), check directory execute permission, check ACLs (getfacl), check if SELinux is blocking access — chmod 777 is an inappropriate security response

A cron job is not executing at the expected time
✕ Wrong instinct

Check whether the service that cron controls is running

✓ Correct approach

Verify cron syntax (crontab -l), check cron daemon status (systemctl status cron/crond), check /var/log/cron for execution errors, verify the user executing the cron job has required permissions

Know these cold

  • Permissions — hmod 755 = rwxr-xr-x; 644 = rw-r--r--; 4=read, 2=write, 1=execute
  • systemctl enable = persist across reboots; systemctl start = current session only
  • Hard links share inodes; symlinks (ln -s) point to paths and break if source is deleted
  • SELinux — nforcing blocks + logs; Permissive logs only; use Permissive only for troubleshooting
  • /var/log/ is where logs live; journalctl is for systemd unit logs
  • Package management — pt/dpkg (Debian/Ubuntu); yum/dnf/rpm (RHEL/CentOS/Fedora)
  • cron syntax: minute hour day month weekday — in that order

Can you answer these without checking your notes?

In this scenario: "A service is not starting after system reboot" — what should you do first?
Use systemctl enable to create the symlink for automatic start at boot — systemctl start only starts it for the current session; enable persists across reboots
In this scenario: "A user reports permission denied when accessing a file they should have access to" — what should you do first?
Diagnose the actual permission issue: check file permissions (ls -l), check directory execute permission, check ACLs (getfacl), check if SELinux is blocking access — chmod 777 is an inappropriate security response
In this scenario: "A cron job is not executing at the expected time" — what should you do first?
Verify cron syntax (crontab -l), check cron daemon status (systemctl status cron/crond), check /var/log/cron for execution errors, verify the user executing the cron job has required permissions

Common Exam Mistakes — What candidates get wrong

Confusing file permission numeric notation with symbolic notation

chmod 755 = rwxr-xr-x; chmod 644 = rw-r--r--. The owner/group/other permission structure (rwx = 4+2+1) must be internalized for both reading and writing the notation.

Misidentifying systemd unit file management commands

systemctl start/stop/restart for runtime control; systemctl enable/disable for boot persistence; systemctl status for current state. Candidates who use start when enable is required fail service management questions.

Confusing hard links with symbolic links

Hard links point to the same inode — deleting the original doesn't remove the data. Symbolic links point to the file path — if the original is deleted, the symlink breaks. ln for hard links; ln -s for symlinks.

Misidentifying SELinux enforcement modes

Enforcing mode: violations denied and logged. Permissive mode: violations logged but not blocked (for troubleshooting). Disabled. Using Permissive mode permanently in production is a security misconfiguration.

Ignoring log file locations for troubleshooting

Key log files: /var/log/syslog or /var/log/messages for system logs, /var/log/auth.log for authentication, journalctl for systemd logs. Candidates who don't know where to look for logs fail troubleshooting scenarios.

Linux+ tests applied Linux administration. Test whether you can administer and troubleshoot Linux in production.