CompTIA Linux+ XK0-005: The Cert Every Linux Admin Needs

Package management — across all major distributions

Candidates need to know the full package toolchain for each major distribution family and understand when to use the high-level tool versus the lower-level tool.

• Debian/Ubuntu: apt for day-to-day package management; dpkg for querying what files a package owns (dpkg -L), which package owns a file (dpkg -S), and installing a local .deb file directly. apt-cache for searching and inspecting available packages before installation.
• Red Hat/CentOS/Fedora: dnf (the current default) and yum (still tested as legacy), with rpm for low-level operations: querying package metadata (rpm -qi), listing installed packages (rpm -qa), and verifying package integrity (rpm -V). Repository configuration lives in /etc/yum.repos.d/ as .repo files.
• SUSE/openSUSE: zypper for package operations; understanding YaST as the GUI management layer without needing to operate it from the terminal.
• GPG key management: verifying package authenticity by importing GPG keys (apt-key add, rpm --import), and understanding why key verification matters for supply chain security.

Storage configuration — LVM, file systems, and NFS

Storage is consistently the highest-complexity topic in Domain 1. LVM is the most exam-weighted storage technology.

• LVM workflow: pvcreate to initialise physical volumes, vgcreate to combine PVs into volume groups, lvcreate to allocate logical volumes from a VG. Extending volumes online with lvextend and resize2fs (ext4) or xfs_growfs (XFS). Creating LVM snapshots for point-in-time backups without unmounting the source volume.
• File systems: ext4 (default on Ubuntu and Debian; journalled, mature, well-supported by recovery tools); XFS (default on RHEL/CentOS; high-performance, cannot shrink online); btrfs (copy-on-write, built-in snapshots and subvolumes, transparent compression). Creating file systems with mkfs.ext4, mkfs.xfs, and mounting with persistent entries in /etc/fstab.
• RAID with mdadm: RAID 0 (striping, no redundancy), RAID 1 (mirroring), RAID 5 (striping with distributed parity, minimum 3 disks), RAID 6 (double parity, survives two simultaneous disk failures). Creating, monitoring, and recovering RAID arrays with mdadm; reading /proc/mdstat for array health.
• Network file sharing: exporting NFS shares via /etc/exports and managing with exportfs; mounting NFS on clients with /etc/fstab or autofs; Samba for cross-platform SMB shares (smb.conf, smbpasswd, testparm).

Kernel, boot, and systemd

• systemd: the init system tested throughout the exam. Service management (systemctl start/stop/enable/disable/status), unit file structure (/etc/systemd/system/), target units as runlevel equivalents (multi-user.target, graphical.target, rescue.target, emergency.target), and journald for structured persistent logging.
• Kernel modules: lsmod (list loaded modules), modprobe (load/unload with dependency resolution), modinfo (inspect module metadata and parameters), /etc/modprobe.d/ for persistent module configuration and blacklisting.
• GRUB2: editing kernel boot parameters at the GRUB menu (press e, modify the linux line), understanding /etc/default/grub and running update-grub or grub2-mkconfig to regenerate the config. Passing systemd.unit=rescue.target or rd.break for single-user/recovery boot.

Permissions, ACLs, and special bits

• Standard permissions: octal and symbolic notation, chmod, chown, chgrp, and umask defaults. Understanding the difference between owner, group, and other permission sets for files versus directories (execute on a directory means traverse, not run).
• Special permission bits: setuid (chmod u+s) causes an executable to run as the file owner rather than the calling user (classic example: /usr/bin/passwd runs as root to write /etc/shadow); setgid on a directory causes new files to inherit the directory’s group rather than the creator’s primary group; sticky bit on a directory prevents users from deleting files they don’t own (classic example: /tmp).
• POSIX ACLs: setfacl to add per-user or per-group permissions on top of the base permission model, getfacl to read ACL entries, and the default: ACL prefix to propagate ACLs to new files created inside a directory.

Mandatory Access Control: SELinux and AppArmor

MAC is the domain 2 topic that most distinguishes Linux+ candidates from those who have only administered permissive Ubuntu systems. SELinux is the default MAC system on Red Hat, CentOS, and Fedora; AppArmor is the default on Ubuntu and Debian.

• SELinux modes: Enforcing (policy violations are blocked and logged), Permissive (violations are logged but not blocked — used for debugging policy), Disabled (SELinux is not active). getenforce reads the current mode; setenforce 0 switches to Permissive temporarily without rebooting; permanent mode is set in /etc/selinux/config.
• SELinux contexts: every file and process has a context label (user:role:type:level). ls -Z shows file contexts; ps -Z shows process contexts. semanage fcontext defines the correct context for a path; restorecon applies it. The common exam scenario: a web server fails to serve a file because the file has the wrong context — fix it with semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?" and restorecon -Rv /srv/web.
• audit2allow: when SELinux blocks an action, an AVC (access vector cache) denial appears in /var/log/audit/audit.log. audit2allow -M mypolicy < /var/log/audit/audit.log generates a policy module that permits the denied action; semodule -i mypolicy.pp loads it. This workflow is exam-tested.
• AppArmor: profile-based confinement; profiles live in /etc/apparmor.d/. aa-status shows loaded profiles and their mode (enforce vs. complain); aa-enforce and aa-complain switch modes. The aa-genprof tool generates a new profile interactively.

Firewall, SSH hardening, and auditing

• Firewall tools: firewalld (zone-based, dynamic, the default on RHEL/CentOS; managed with firewall-cmd); iptables (rule-based, still required knowledge for legacy systems); nftables (the kernel netfilter replacement, more consistent syntax, underlies both firewalld and iptables on modern kernels).
• SSH hardening: /etc/ssh/sshd_config directives — PermitRootLogin no, PasswordAuthentication no (enforces key-only auth), AllowUsers/AllowGroups to restrict who can connect. ssh-keygen to create key pairs; ssh-copy-id to deploy public keys. ~/.ssh/authorized_keys permission requirements (600 for the file, 700 for the directory).
• sudo and PAM: /etc/sudoers syntax (always edit with visudo to prevent syntax errors that lock out sudo access); user and group-based rules; NOPASSWD for automation accounts. PAM (/etc/pam.d/) for pluggable authentication: password complexity requirements (pam_pwquality), account locking after failed attempts (pam_faillock), and session recording.
• auditd: the Linux audit daemon writes security-relevant events to /var/log/audit/audit.log. auditctl -w /etc/passwd -p wa -k identity-change adds a watch on file writes; ausearch -k identity-change queries by key; aureport generates summaries. Understanding auditd is a differentiator for candidates targeting government or compliance-heavy environments.

Bash scripting

• Script structure: shebang (#!/bin/bash), variables (VAR=value, no spaces around =), positional parameters ($1, $2, $@ for all arguments), and $? for the exit code of the previous command.
• Conditionals and loops: if/elif/else/fi with [[ ]] test syntax; case for multi-branch string matching; for loops over lists and globs; while loops with a condition; reading files line-by-line with while IFS= read -r line.
• Common exam tasks: write a script that checks disk usage and sends an alert if above a threshold; iterate over a list of servers and run a command on each; parse /etc/passwd to extract usernames; back up a directory with a timestamp in the filename. These are realistic automation tasks that a Linux admin writes in production — the exam tests whether the candidate can write and read them, not whether they can pass a bash trivia quiz.
• Python awareness: the exam may present a short Python script and ask the candidate to explain what it does or identify an error. Candidates do not need to write Python from scratch, but should be able to read basic Python that uses os, sys, subprocess, and file I/O.

Containers: Docker and Podman

Both Docker and Podman are in scope. The key exam distinction is architectural: Docker requires a running dockerd daemon (and traditionally ran containers as root, making daemon compromise a significant security risk); Podman is daemonless (each container is a direct child process of the calling user, enabling rootless containers without a privileged daemon).

• Core container operations: docker pull / podman pull to fetch images; docker run / podman run with flags for port mapping (-p 8080:80), volume mounts (-v /host/path:/container/path), environment variables (-e KEY=value), and detached mode (-d).
• Dockerfile: FROM (base image), RUN (execute commands during build), COPY (copy files from build context), EXPOSE (document a port), ENV (set environment variables), CMD (default command, overridden by arguments to docker run), and ENTRYPOINT (fixed entry point, arguments to docker run are appended). docker build -t myimage:tag . to build from a Dockerfile.
• Container networking: bridge network (containers on the same host communicate via a virtual bridge; default mode), host network (container shares the host network stack; maximum performance, reduced isolation), none (container has no network access). docker network ls, docker network create, and connecting containers to named networks for service-to-service communication.
• Volume management: named volumes (managed by Docker/Podman, persistent across container removal) versus bind mounts (a host directory mounted into the container path, useful for development). docker volume ls, docker volume inspect, and docker volume prune.

Automation with Ansible

• Architecture: Ansible is agentless — it connects to managed hosts over SSH and executes tasks using Python on the target. No agent installation required. The control node runs Ansible; the managed nodes only need SSH access and Python. This contrasts with Puppet’s agent-based pull model (agents on each managed node check in with the Puppet server for their catalog).
• Inventory and playbooks: the inventory file lists managed hosts (in INI or YAML format, grouped by role); a playbook is a YAML file containing plays, each targeting a host group and listing tasks. Common modules tested: apt and yum for package management, copy and template for file deployment, service for managing services, user and group for account management.
• Idempotence: a core Ansible principle. A correctly written playbook can be run multiple times and produces the same end state — tasks that have already been applied are skipped rather than reapplied. The changed vs. ok status in Ansible output reflects this: changed means the task modified something; ok means the desired state was already present.

Storage troubleshooting

• Disk and file system health: df -h for file system usage (what is mounted and how full); du -sh /path for directory sizes; lsblk for a block device tree showing which devices are partitioned and mounted; fsck for file system check and repair (must be unmounted or the system must be in single-user mode).
• Full disk diagnosis: the common scenario is a root partition at 100%. Approach: find / -xdev -size +100M 2>/dev/null to locate large files; lsof +L1 to find files that have been deleted but are still held open by a process (the space is not freed until the file handle is closed — restart the process to release it); journalctl --vacuum-size=500M to trim journal logs.
• I/O performance: iostat -x 1 for per-device utilisation and await times; iotop for per-process I/O; blkid for block device UUID identification (used to match fstab entries to devices).

Network troubleshooting

• Interface and routing: ip addr show for interface addresses and state; ip route show for the routing table; ip link set eth0 up/down for interface state; nmcli device status and nmcli connection show for NetworkManager-managed systems; nmtui for a terminal UI to edit connections persistently.
• Connectivity testing: ping for ICMP reachability; traceroute and mtr for path analysis; ss -tlnp (the modern replacement for netstat) to list listening TCP sockets with the owning process; nmap for scanning from another host to verify firewall rules are actually permitting expected traffic.
• Packet capture: tcpdump -i eth0 port 80 -w capture.pcap captures traffic to a file; tcpdump -r capture.pcap reads it. Knowing when to use ss (to see what is listening locally) versus tcpdump (to see what is actually transiting the wire) is an exam-tested distinction.
• DNS troubleshooting: dig for DNS resolution queries (showing the full answer section, authoritative vs. cached); nslookup; checking /etc/resolv.conf for configured nameservers; /etc/nsswitch.conf to understand the resolution order (files then DNS).

Application and boot troubleshooting

• systemd diagnosis: systemctl status <service> shows recent log output and the last failure reason; journalctl -u <service> --since "1 hour ago" retrieves the full service log for a time window; journalctl -p err filters to error-level and above across all units.
• dmesg and hardware issues: dmesg | tail -20 for recent kernel messages (hardware errors, driver loading failures, OOM killer events); dmesg -T for human-readable timestamps.
• strace and ldd: strace -p <PID> traces system calls on a running process (what files is it trying to open? what system calls are failing?); strace ./myprogram 2>&1 | grep ENOENT to isolate missing file errors. ldd /usr/bin/myapp lists shared library dependencies and shows which are missing (reported as “not found”).
• Boot recovery: rd.break as a kernel boot parameter drops the system into a shell before the real root file system is mounted, with the initrd still active — used to reset a forgotten root password on RHEL/CentOS by remounting the root file system read-write, chrooting into it, and running passwd root. Knowing the exact steps for this RHEL root password recovery procedure is consistently exam-tested.