XK0-006 CompTIA Linux+ (V8) Study Guide

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. Objective coverage, citations, volatility labels, links, and exam-integrity compliance were checked on October 29, 2026. See the sources-and-objectives record. The official Linux+ page is authoritative.

Study guide at a glance

Start here

Report an issue with XK0-006

Blueprint checked2026-10-29

Review stateSources + objectives checked — human review pending

Guide-only active reading1 hr–1 hr 30 min

Prerequisites: CompTIA recommends about 12 months of Linux server experience. Practice on Debian- and RPM-family systems: boot/kernel/devices, LVM/RAID/filesystems/mounts, network/shell/backups/virtualization, users/permissions/processes/packages/systemd/containers, authentication/firewalls/hardening/cryptography/compliance, Bash/Python/Git/automation/AI review, and evidence-led break/fix with persistent revalidation after reboot.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Original Bash file-inspection exercise, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

• See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Linux+ V8, exam XK0-006; launched July 15, 2025
Lifecycle watch: No exact retirement date is announced. CompTIA says an exam usually retires three years after launch and estimates 2028; verify before scheduling.
Official delivery snapshot: Maximum 90 multiple-choice and performance-based questions; 90 minutes; 720/900 passing score; English listed
Experience guidance: CompTIA recommends about 12 months of hands-on Linux server experience

How to use this guide

Linux+ evaluates administration, not a memorized command dictionary. For every task, build the same evidence loop:

1. inspect identity, distribution/version, runtime state, configuration, dependencies, logs and resource impact;
2. predict the narrowest safe change and its permissions, target, persistence and rollback;
3. make the change in a disposable or authorized environment;
4. validate the direct result plus service, security, logging and dependent application behavior;
5. reboot or recreate where persistence matters, validate again, and document exact commands/output.

Practice on at least one Debian-family and one RPM-family system or container/VM where feasible. Translate package, network, firewall, mandatory-access-control and configuration locations instead of assuming a universal implementation. Before any destructive storage, account, firewall or network action, confirm the target and retain a working console/snapshot/backup path.

Weighted objective map

Domain	Weight	Readiness evidence
1. System management	23%	Explain boot/kernel/filesystems/architectures; manage devices, storage, network, shell, backup/restore and virtualization
2. Services and user management	20%	Manage files/links/permissions, accounts, processes/jobs, packages/repos, systemd/logs/timers and containers
3. Security	18%	Configure authentication/accounting, firewalls, hardening, accounts/remote access, cryptography/integrity and compliance evidence
4. Automation, orchestration, and scripting	17%	Use automation/IaC concepts, Bash, Python, Git/CI/CD and responsible AI-assisted code workflows
5. Troubleshooting	22%	Correlate system/log evidence to boot, storage, network, security and performance causes, then repair and revalidate

CURRENT BLUEPRINT: The public XK0-006 objectives PDF, document version 5.0 contains 29 numbered objectives, in groups of 7/6/6/5/5. Find it through CompTIA’s resource portal. The main page has 29 summary rows; the PDF adds command-level detail. Document version 5.0 is separate from exam V8.

Published IDs	Coverage and evidence
1.1–1.3	Linux foundations, devices, storage
1.4–1.7	Networking, shell operations, backup/restore, virtualization
2.1–2.3	Files/directories, local accounts, processes/jobs
2.4–2.6	Software/services, systemd, containers
3.1–3.3	Authentication/accounting, firewall, OS hardening
3.4–3.6	Account hardening, cryptography, compliance/audit
4.1–4.5	Automation/orchestration, shell, Python, Git, responsible AI
5.1–5.5	Monitoring, system/storage, networking, security, performance troubleshooting

VERIFY CURRENT: Recognize the published terminology, then check the installed implementation. The outline names some older tools and has command-name inconsistencies; the implementation notes below explain these without silently changing the exam scope.

1. System management — 23%

Boot, kernel, hardware, and filesystems

Trace boot from firmware (BIOS/UEFI) through boot device/loader (commonly GRUB), kernel and initramfs, PID 1/systemd targets and services to login/workload. Know where failure evidence appears: firmware/console, bootloader configuration, kernel command line/messages, initramfs, journalctl -b, units/dependencies and filesystem checks. A running system may still have a broken next boot, so validate generated boot configuration and persistent files before restart.

The kernel mediates CPU, memory, devices, filesystems, network and processes. Inspect release and architecture with uname, CPU/memory with /proc, lscpu/free, devices with lspci, lsusb, lsblk, udevadm and kernel messages. lsmod, modinfo, modprobe and module configuration manage drivers; loading a module now is different from arranging it at boot. Distinguish x86_64, ARM and other architectures when choosing packages/images.

The filesystem hierarchy gives common intent: /etc configuration, /var changing service data/logs, /home users, /root root home, /usr installed userland, /boot boot artifacts, /dev devices, /proc and /sys kernel views, /run runtime state, /tmp temporary data, and /opt/srv for optional/service content by policy. Mounting attaches a filesystem at a directory; it is not the same as formatting or partitioning.

Related item: Runtime state, persistent configuration and generated state are different. Editing a generated file can appear to work until the owning tool or next boot replaces it.

Objective 1.1 also covers PXE/network boot, graphical components and licensing. Separate the display manager’s login/session role from a window manager/compositor and the display protocol/server; X and Wayland architectures are not interchangeable configuration recipes. AArch64, RISC-V, x86 and x86_64 labels identify architecture families, not package compatibility guarantees. Free/open-source, proprietary and copyleft terms describe different permission/licensing dimensions; inspect the specific license and organizational obligations before redistribution.

For devices, distinguish module dependencies (depmod), direct insertion (insmod) and dependency-aware loading (modprobe). A driver present on disk may be absent from the early-boot image. Initrd/initramfs generation tools and boot configuration differ by distribution; inspect the current tool’s output and retain recovery access. Embedded/GPU management needs the matching driver, firmware, architecture and workload support, not merely a detected PCI device.

Storage and recovery

Inventory disks/partitions/filesystems/mounts with lsblk, blkid, findmnt, df and du. Partition tables and partitions precede filesystems; filesystem labels/UUIDs support stable mounts. /etc/fstab defines persistent mounts and options. Verify with a non-destructive mount test before reboot; a bad root/critical entry can prevent normal boot.

LVM separates physical volumes, volume groups and logical volumes, permitting allocation and growth; filesystem growth is a separate step. Shrink support varies and is riskier. RAID levels trade capacity, performance and failure tolerance but do not replace backup. Swap provides memory pressure capacity, not ordinary storage. Network filesystems and object/block/file services have identity, availability and consistency dependencies.

Before repair or resizing, identify the exact device, protect data, unmount/offline as required, check filesystem/tool support and preserve recovery access. Use filesystem-specific check/repair tools only under correct conditions. tar, cpio, rsync and compression tools solve different archive/synchronization needs. A backup is proven by integrity, protected retention and restore testing—not a successful command exit alone.

PRACTICAL DEPTH — storage boundaries: Allocating a larger LV does not automatically prove that its filesystem grew. A VG with 4 MiB extents needs 256 free extents for an additional 1 GiB allocation, before considering the actual layout and command semantics. Check free extents, LV size, filesystem support and mounted capacity separately. A full inode table can prevent new files even when data blocks remain; a deleted but still open file can consume blocks while disappearing from a directory walk.

For rsync, a trailing slash on the source directory means copying its contents rather than adding that directory’s name. Archive mode -a does not include ACL, extended-attribute or hard-link preservation (-A, -X, -H respectively). Permissions, privilege, filesystem and both endpoint capabilities still matter. Preview with the intended options and inspect itemized differences before a real run; a dry run is not restore evidence. --delete can remove destination-only files and requires a deliberate, reviewed scope. No rsync transfer ran in this review.

Network, shell, and virtualization

Inspect addresses/links/routes/neighbors with ip, DNS/resolution with resolvectl or configured resolver files/tools, sockets with ss, path/reachability with ping and traceroute/tracepath, names with dig/host, and captures with tcpdump only when authorized. Separate runtime configuration from NetworkManager, netplan, systemd-networkd or distribution-specific persistence. A correct address does not prove route, DNS, firewall, service or return path.

In the shell, quote variables, understand expansion/globbing, redirects (>, >>, 2>, pipes), command substitution, exit status and environment versus shell variables. Use pwd, cd, ls, cp, mv, rm, mkdir, find, grep, sed, awk, cut, sort, uniq, xargs, tee, editors and help/man pages safely. Treat paths beginning with -, spaces/newlines, symlinks, recursion, privilege and command output as hazards. Preview selections before bulk change.

Virtualization uses a hypervisor, VM definition, virtual CPU/memory/network and disk images. Thin provisioning, snapshots, clones/templates and guest tools have capacity, consistency and security tradeoffs. A snapshot is not automatically an independent backup. Know hosted versus bare-metal concepts, bridges/NAT/isolated networking, image formats and cloud-instance differences; validate boot, network, time and storage after cloning/restoration.

Published names versus installed commands

PDF wording	Implementation distinction
nmconnect under NetworkManager	Upstream documents nmcli and nmtui, including nmtui connect / nmtui-connect. Verify the actual package/help; do not assume nmconnect is a portable executable.
vit-manager in virtualization	The upstream project is virt-manager, a graphical libvirt management tool; virt-install, virt-clone and virt-xml have separate roles.
systemd-blame in system management	Use systemd-analyze blame for the documented subcommand. It is not a universal systemd-blame executable.
<<< grouped with here-documents	Bash distinguishes a here-string (<<<) from a here-document (<<). The former supplies an expanded string plus newline; quoting the latter’s delimiter suppresses body expansion.

NetworkManager profiles, Netplan definitions and kernel runtime state are different layers. Inspect the renderer/owner before changing files. NetworkManager can reread a changed profile without automatically proving the active device adopted every change. Use distribution-supported workflows and verify addresses, routes, resolver selection and reconnect/reboot behavior in a lab.

2. Services and user management — 20%

Files, permissions, links, and special files

Linux permissions apply to owner, group and other with read/write/execute meanings that differ for files and directories. Numeric modes combine bits; symbolic mode expresses targeted change. Ownership uses numeric UID/GID underneath names. Setuid, setgid and sticky bits have special behavior and security risk; ACLs add named access; umask clears requested creation-mode bits; it is not arithmetic subtraction. Evaluate every path component and active identity when troubleshooting access.

Hard links are additional names for one inode and normally cannot cross filesystems; symbolic links store another path and can become dangling. FIFOs, sockets, block and character devices are special file types. Use stat, file, readlink, namei, getfacl/setfacl and find to explain behavior. Avoid recursively changing ownership/mode until scope, symlinks, mount boundaries and application expectations are known.

Creation modes and ACL masks

The Linux umask interface applies requested_mode & ~umask when no default ACL changes the creation rules. A typical regular-file request of 0666 with mask 0022 yields 0644; directory request 0777 yields 0755. With mask 0003, 0666 becomes 0664, not 0663. A umask removes permissions; it does not add execute permission or retroactively change existing files.

The ACL model limits named-user, owning-group and named-group entries through the ACL mask. For example, named user lab-reader:rwx with mask r-x has effective r-x; owner and other entries are outside that mask. When an extended ACL exists, the displayed group-class mode bits correspond to the mask, so chmod g... can affect effective named-entry permissions. A parent default ACL changes creation inheritance, still constrained by the requested mode.

Directory write and search permissions govern adding/removing names, with sticky-bit and other policy restrictions; a file’s own write bit does not alone control deletion. Setgid on a directory supports group inheritance; sticky constrains removal/rename in shared directories. Verify the complete path, effective identity and mandatory access policy. The arithmetic above was checked as a model; native Linux ACL/mode enforcement was not executed here.

Accounts, processes, jobs, and software

/etc/passwd, /etc/shadow, /etc/group and related databases describe local accounts; use account tools (useradd/usermod/userdel, groupadd/groupmod, passwd, chage) rather than unsafe direct edits. Understand UID/GID, primary/supplementary groups, home, shell, locked/expired state, system versus interactive accounts and skeleton files. Removal requires deliberate decisions about owned files, jobs, keys, tokens and audit retention.

Inspect processes/threads and hierarchy with ps, top/htop, pgrep, /proc, pstree; signal with kill/pkill after confirming PID/owner; adjust scheduling using nice/renice; manage foreground/background, jobs, nohup and terminal/session implications. Process state such as running, sleeping, stopped or zombie is evidence, not a diagnosis. Schedule recurring tasks with systemd timers or cron according to environment; record identity, environment, working directory, logging, overlap, failure and missed-run behavior.

Debian-family APT/dpkg and RPM-family DNF/YUM/rpm use different commands and metadata. Verify repository trust/signatures, release/version, architecture, dependencies, configuration-file handling and service/reboot needs. Source builds need toolchain, dependency, prefix, ownership and update strategy. Never enable an unknown repository or pipe an unreviewed Internet script to a privileged shell.

A locked password is not automatically a revoked SSH key, token, running session or job. UID ranges and account-management defaults vary by distribution; inspect the local policy rather than treating one number as universal. Polkit authorizes selected privileged operations; NSS/SSSD/Winbind, PAM and Kerberos serve distinct lookup, integration, authentication and session roles.

For software, objective 2.4 includes DNS, time, DHCP, HTTP, SMTP and IMAP service configuration as well as installation. For each service, identify its listening endpoint, configuration validator, service identity, data location, trust/permission boundary, logs and a protocol-level check. A package installed successfully can leave a service disabled, misconfigured or unreachable. System language packages and application virtual environments have different owners; do not overwrite distribution-managed Python merely to satisfy one application dependency.

Services, logs, timers, and containers

With systemd, distinguish unit file, enabled boot relationship, current active state, failed condition and dependencies. Use systemctl status/start/stop/restart/reload/enable/disable/mask, systemctl cat, systemctl list-dependencies, journalctl -u/-b and systemd-analyze as appropriate. Reload and restart differ; daemon-reload rereads unit definitions, not service configuration. Validate configuration syntax before restart and preserve a rollback/console path for remote services.

Logs may be in journald, rsyslog/syslog files and application-specific locations. Query by unit, boot, time, priority and identifier; ensure clocks, rotation, retention, permissions and remote forwarding. Absence can mean wrong query/source, rate limit, rotation or logging failure—not absence of an event.

Container runtimes manage images, registries, containers, networks, volumes, environment/secrets and lifecycle. An image is immutable template content; a container adds runtime state; a volume persists data outside the writable layer. Pin and scan trusted images, avoid privileged/root use where possible, restrict capabilities/mounts/network/resources, protect registry credentials and logs, and recreate to prove declarative persistence.

Related item: Service health is an end-to-end property. “Active” PID state does not prove a listening socket, firewall path, dependency, authenticated request, correct data or recovery after reboot.

Unit state, timers and boot evidence

systemctl separates activation from enablement. Enabling usually installs start relationships and does not start the service unless requested; disabling does not itself stop an already running service. Masking blocks activation but does not implicitly stop the process without the corresponding action. A static unit can start through dependencies even though it is not conventionally enabled. Check load, active and sub-state plus the unit’s type and result.

Timer units distinguish wall-clock OnCalendar= expressions from monotonic timers. Persistent=true applies to calendar timers and can trigger a catch-up activation after an inactive period; it does not replay every missed interval as an independent job. Accuracy windows and randomized delay affect timing. An already active target service is not restarted merely because the timer elapses. Define job identity, input, logging and concurrency at the service/application level.

systemd-analyze blame ranks activation duration, not proven responsibility for the entire boot delay. Units can run in parallel or wait on dependencies, and some types have no meaningful activating interval. Compare critical-chain, the journal and a timeline before disabling a service. These are documented diagnostic workflows, not commands executed against a Linux service manager during this review.

3. Security — 18%

Authentication, authorization, and accounting

PAM stacks authentication, account, password and session modules; order/control flags matter, so keep a second privileged session and tested recovery before changes. LDAP supplies directory access; Kerberos provides ticket-based authentication and depends strongly on DNS and time. NSS determines name-service lookups. MFA adds independent factors but must include enrollment/recovery and service/non-interactive account design.

Use least privilege through groups, file/ACL ownership, capabilities, service isolation and narrowly scoped sudo. Edit sudo policy with validation and test as the intended user. Secure SSH with supported crypto, host-key verification, controlled user/group/source access, key protection, disabled direct root/password use where appropriate, MFA/jump paths and logs. Do not remove the only working remote path before testing an alternate.

Accounting and auditing include login/session records, sudo/auth logs and Linux Audit rules/events. Define what must be recorded, protect and forward it, time-synchronize, tune volume and test retrieval. Logging secrets or excessive personal data creates its own risk.

CURRENT BLUEPRINT / VERIFY CURRENT — failed-login tracking: Objective 3.4 still names pam_tally2. Upstream Linux-PAM release notes removed deprecated pam_tally and pam_tally2 in version 1.5.0 and directs users to pam_faillock. The faillock module documentation explicitly says its PAM-stack setup differs. Recognize the older exam term; use the installed distribution’s supported module and configuration mechanism. Do not mechanically replace a module name or copy a generic stack into a live login service. No PAM or account policy was changed.

Firewalls, hardening, cryptography, and compliance

iptables, nftables, UFW and firewalld/zones can represent packet-filter intent through different layers. Understand default policy, chain/hook, direction, interface, state, source, destination, protocol/port and rule order. Determine which frontend owns the rules; do not mix tools blindly. Test allowed and denied flows plus persistence, IPv4/IPv6 and lockout recovery.

Harden through supported releases/patches, minimal packages/services, secure boot/firmware where applicable, file/permission/ACL review, sudo, SSH, firewall, SELinux/AppArmor, mount options, kernel parameters, logging/audit, integrity monitoring, vulnerability/configuration scanning and tested backup. SELinux labels/types and policy decisions differ from Unix mode bits; AppArmor uses path-oriented profiles. Do not disable enforcement as the final fix—find the needed access and implement the narrow supported change.

Use modern tools for file/disk encryption and TLS/SSH; hash for integrity/password storage according to purpose; manage certificates, trust, expiry and private keys. Protect secrets from shell history, process arguments, environment, repositories, images and logs. Validate file integrity with signed packages/baselines or tools such as AIDE according to policy.

Compliance work maps an applicable requirement/benchmark to configuration and evidence, documents exception/compensation and remediates drift. A scanner finding needs version/exposure/business validation. Never equate “passed scan” with secure system or apply a benchmark without workload impact testing.

Related item: Effective access is the intersection of Unix permissions/ACLs, mandatory access control, mount options, service sandboxing, identity/session state and application policy.

Backports, integrity and sanitization limits

Red Hat’s backporting explanation shows why an upstream version string alone can produce a false-positive vulnerability finding. Check the exact distribution package/release, vendor advisory, affected component and installed fix state. This is not permission to dismiss a scanner alert merely because a vendor sometimes backports. The article’s older package examples illustrate the method, not a current supported-release recommendation.

A hash compares bytes against a reference whose integrity you must protect; HMAC adds a secret-key authentication relationship, and a signature uses an asymmetric key relationship. A self-signed private test certificate is not automatically trusted by another client; deliberate private trust and identity verification are different from accepting an unknown certificate warning. Do not weaken TLS verification to make a test pass.

The PDF’s destructive tools require implementation limits. NIST SP 800-88 revision 2 distinguishes sanitization methods and verification/validation. File overwriting cannot universally reach SSD remapped blocks, snapshots or other copies; cryptographic erasure depends on the actual key/data design. badblocks -w is destructive testing, not a harmless health query. No block device, real media or existing user data was modified or erased.

4. Automation, orchestration, and scripting — 17%

Configuration automation and delivery

Configuration tools such as Ansible and Puppet express desired state through inventories/manifests, modules/resources, variables, templates, handlers/dependencies and secrets. Understand agentless/agent patterns, push/pull, idempotence and drift. Infrastructure/code should be versioned, reviewed, linted/tested, deployed to a small scope, observed and reversible. CI/CD connects commit, build/test/security gates, artifact, approval, deployment and rollback; pipeline credentials must be least privilege.

Containers and orchestrators schedule images/workloads with networks, storage, configuration/secrets, health and resource controls. Objective 4.1 explicitly names OpenTofu, Ansible, Puppet, Kickstart, cloud-init, Kubernetes, Docker Swarm and Docker/Podman Compose. Map each to provisioning, initial configuration, configuration management or workload orchestration; the main-page summary is less detailed. OpenTofu state binds declared resources to remote objects and needs protected access, backups and supported change procedures. A state operation that forgets an object is not proof the object was destroyed. See OpenTofu state guidance.

Bash and Python

A safe shell script declares an interpreter, handles arguments, quotes expansions, validates input/target/privilege, checks exit status, uses functions and control flow, emits useful logs/errors, avoids secrets and has a dry-run/test/rollback story. Understand variables, positional parameters, arrays where used, if/case, for/while, tests, functions, pipelines/subshell effects and traps. set -e is not a substitute for deliberate error handling.

Python basics include interpreter/virtual environment, modules/packages, variables and types, lists/dictionaries, conditionals/loops, functions, exceptions, files/structured data and command-line arguments. Pin/trust dependencies, avoid system-package conflicts, close resources and make failure explicit. Use the standard library when sufficient and a virtual environment for application dependencies.

Original Bash file-inspection exercise

This script inventories a static, owned practice directory without reading file contents or changing settings. Bash’s manual explains quoting, read, pipelines and error handling; the GNU Findutils manual describes NUL-delimited filename handling. Direct Findutils PDF retrieval was intermittent; its indexed official safe-filename section and the installed tool’s help supplied the specific option evidence.

Save as list_regular_files.sh and invoke with bash list_regular_files.sh ./practice-tree. NUL separates names that may contain spaces or newlines; printf %q makes display safer to inspect. Do not evaluate that display as commands. Check the process exit status before accepting output, since a failed traversal can emit partial results.

#!/usr/bin/env bash
# Inspect one static, owned lab directory. No file content or settings are changed.
set -u
set -o pipefail

if (( $# != 1 )); then
    printf 'Usage: bash list_regular_files.sh DIRECTORY\n' >&2
    exit 2
fi
root=$1
if [[ ! -d "$root" || -L "$root" ]]; then
    printf 'Expected an existing, non-symlink lab directory.\n' >&2
    exit 2
fi
# Prefix relative paths so a leading hyphen cannot become a find option.
[[ $root == /* ]] || root=./$root

find -P "$root" -type f -print0 | {
    count=0
    while IFS= read -r -d '' file; do
        printf '%q\n' "$file"  # Escaped display, not a command to evaluate.
        ((count += 1))
    done
    printf 'regular_files=%d\n' "$count"
}
# pipefail propagates a failed find. Output may be partial on failure.
# By default this pipeline group runs in a subshell; do not rely on count afterward.

Without pipefail, a successful final stage can hide an earlier failure. pipefail reports the rightmost nonzero stage, not necessarily the first failure. Pipeline loops normally run in a subshell, so an updated variable may not survive outside it; Bash’s lastpipe option is a qualified exception. set -e has context-dependent exceptions, including tests, and does not replace explicit handling. This exercise assumes the tree is not concurrently modified; it is not an adversarial filesystem-race defense.

Original restore comparison

Save this Python 3.13 example as compare_restore.py. It uses pathlib and hashlib to compare two static practice trees. Invoke python compare_restore.py ./practice-tree ./restored-tree; exit zero means the checked names, directory structure and file hashes agree. Exit one reports differences; invalid input or access errors fail visibly.

"""Compare two static, owned practice trees; refuse symlinks and junctions.

This checks names, directory structure and file bytes, not Linux ownership,
ACLs, xattrs, timestamps, sparse layout or application consistency.
"""
import argparse
import hashlib
import json
import os
from pathlib import Path


def tree_manifest(root):
    root = Path(root)
    if root.is_symlink() or root.is_junction() or not root.is_dir():
        raise ValueError('Expected a non-link directory.')
    root = root.resolve(strict=True)
    directories, files = [], {}

    def fail(error):
        raise error

    for current, names, leaves in os.walk(root, followlinks=False, onerror=fail):
        for name in sorted(names + leaves):
            path = Path(current) / name
            if path.is_symlink() or path.is_junction():
                raise ValueError('Links are outside this practice comparison.')
            relative = path.relative_to(root).as_posix()
            if path.is_dir():
                directories.append(relative)
            elif path.is_file():
                with path.open('rb') as stream:
                    digest = hashlib.file_digest(stream, 'sha256').hexdigest()
                files[relative] = digest
            else:
                raise ValueError('Unsupported file type.')
    return {'directories': sorted(directories), 'files': files}


def compare(left, right):
    a, b = left['files'], right['files']
    return {
        'missing_files': sorted(a.keys() - b.keys()),
        'extra_files': sorted(b.keys() - a.keys()),
        'changed_files': sorted(k for k in a.keys() & b.keys() if a[k] != b[k]),
        'missing_directories': sorted(set(left['directories']) - set(right['directories'])),
        'extra_directories': sorted(set(right['directories']) - set(left['directories'])),
    }


if __name__ == '__main__':
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument('source')
    parser.add_argument('restored')
    args = parser.parse_args()
    result = compare(tree_manifest(args.source), tree_manifest(args.restored))
    print(json.dumps(result, indent=2, ensure_ascii=True))
    raise SystemExit(1 if any(result.values()) else 0)

The comparator refuses links/junctions as a deliberately limited exercise; it is not a full backup product or a race-resistant path sandbox. It does not prove owners, ACLs, xattrs, timestamps, sparse allocation, hard-link relationships or application consistency. Protect archives and extract into a separate controlled directory; GNU tar’s security guidance explains why archive contents and writable ancestor paths matter.

Executed September 29, 2026: both examples and a harness passed 44 checks with Windows Python 3.13.14 and Git for Windows’ MSYS Bash 5.3.15, GNU tar 1.35 and Findutils 4.11.0. Six synthetic files included spaces, leading hyphens, quotes, binary/empty content and MSYS-mapped unusual names. An actual archive/restore preserved the checked names, empty directory and bytes. Altered, missing and extra entries were detected; a simulated failed find propagated its nonzero exit. Owned temporary files were cleaned up.

This is Bash/GNU utility execution through MSYS, not native Linux filesystem or kernel verification. Permission/ACL, extent and SLO calculations were models. No native systemd/PAM, firewall, network, account, storage-device, VM/container or full distribution lab ran; the Linux runtime startup blocker remains deferred.

Git and responsible AI assistance

Use clone/status/diff/add/commit/log, branches, merge/rebase concepts, remote fetch/pull/push, tags and ignore rules. Commits should be reviewable and free of secrets/binaries/generated state unless intentionally managed. Resolve conflicts by understanding both changes and retesting. Tags can mark releases but require governance/signing to strengthen trust.

AI can explain an error, draft code/tests/docs or compare approaches, but prompts/outputs can expose sensitive data and generated commands can be incorrect, insecure, destructive or version-incompatible. Provide sanitized minimum context; require source/version verification, code review, static/security checks, isolated execution and human accountability. Never paste secrets or production data, and never run generated privileged commands unread.

Related item: Idempotence means repeated execution converges safely; it does not mean the desired state is correct, authorized, secure or free from side effects.

5. Troubleshooting — 22%

Method and evidence

Define exact symptom, scope, time, impact, expected behavior, recent change and reproduction. Capture baseline and logs before modifying. Form a theory across layers, run the least-invasive discriminating test, plan with risk/rollback/approval, implement one change, verify direct/dependent/security/reboot behavior and document. Use local documentation and distribution release notes; commands and paths change.

Core evidence includes journalctl, logs, dmesg, systemctl, ps/top, free, vmstat, iostat, sar, uptime, df/du/findmnt/lsblk, lsof, ss, ip, DNS/path/capture tools, package history, audit/MAC logs and application-specific diagnostics. Time-align evidence. A busy process, full cache or single log message may be correlation rather than cause.

Monitoring — objective 5.1

CURRENT BLUEPRINT: Define an SLI as the measured indicator, an SLO as its target and an SLA as an agreement with specified commitments. Choose the population, exclusions, time window and data source before calculating a percentage. For a hypothetical time-based 99.9% availability target over 30 days, the allowed unavailable time is 43.2 minutes; a request-based SLI of 9,990 successful requests out of 10,000 is also 99.9%, but it measures a different quantity. Do not substitute one for the other or infer contractual consequences from this arithmetic.

An SNMP trap, webhook, agent heartbeat, health probe and application log have different collection and failure paths. Track collector health, missing data, timestamp skew, thresholds, alert routing and response ownership. A host-up probe can remain green during an authenticated application outage. The synthetic SLI and time-budget arithmetic was checked; no real uptime or monitoring deployment was measured.

Boot, hardware, storage, and application

For boot failure, locate the boundary: firmware/device, bootloader, kernel/initramfs/module, root filesystem/mount, systemd target/unit or application. Use console/rescue/emergency access and preserve data. For a kernel/module issue, compare last-known-good kernel, module dependency/configuration, hardware/firmware and logs; do not delete boot artifacts blindly.

Storage symptoms can come from capacity versus inodes, deleted-open files, permissions, read-only remount, failed path/device/RAID member, LVM exhaustion, bad fstab, filesystem corruption or application quotas. Confirm identity before repair. Application/service failure can be config syntax, permission/MAC, port conflict, dependency, certificate/time, resource limit, package/library mismatch or data path; inspect service and application logs plus a direct local request.

Network, security, and performance

For network failure, test link/interface, address/prefix, neighbor, route/default, DNS, firewall, listening socket, service/TLS/identity and return path. Compare name and direct-IP tests. Preserve remote console before changing routes/firewall/SSH. Distinguish runtime from persistent configuration and test IPv4/IPv6 as applicable.

Permission failure requires the effective user/groups, every directory component, owner/mode/ACL, SELinux/AppArmor denial, mount options, service sandbox and application rule. Vulnerability remediation requires version/package source, exposure, exploit context, owner/maintenance risk, update/config/compensation, validation scan and rollback. Do not disable security globally to suppress one denial.

CPU saturation, run queue, memory pressure/swap, disk latency/queue, filesystem fullness, network loss/latency, lock/contention and application dependency can all feel “slow.” Correlate time-series CPU, memory, I/O, process, network and workload evidence. Nice priority affects CPU scheduling, not every bottleneck. Tune only after identifying constraint; then load-test, monitor regression and preserve capacity/recovery margin.

Related item: A workaround restores service; root-cause correction removes the enabling condition; prevention adds detection, capacity, test or process change so recurrence is less likely.

Integrated scenarios

Scenario 1: Remote server fails after storage change

Use console access, capture boot/journal and block/mount state, compare the change and fstab to UUIDs/filesystem support, protect data, and test a temporary mount. Correct the persistent entry with backup/rollback, validate files/permissions/service data, reboot, recheck mounts/services/logs and update documentation. Do not format a device to “make it mount.”

Scenario 2: Web service is active but unreachable

Confirm process, listening address/port, local request, configuration syntax, certificate/time, firewall frontend/rules/persistence, SELinux/AppArmor, interface/route/DNS and upstream policy. Correct the narrow fault, test allowed and denied paths from an authorized client, restart/reload safely, reboot if persistence is in question, and record root cause.

Scenario 3: Automated container update leaks a secret

Stop further deployments without destroying evidence; identify repository/pipeline identity, image/tag/digest, logs/artifacts and affected runtime. Revoke/rotate the secret, remove it from history/artifacts where feasible, rebuild from trusted inputs, scan/test/pin, deploy canary, verify workload/network/storage/logging and add secret scanning/scoped credentials/approval. Treat Git history rewrite and image deletion as governed changes, not proof the secret was unseen.

Hands-on labs

All eight complete Linux labs remain proposed. The MSYS/Python examples above are narrower execution evidence. Use disposable machines, synthetic data, exact target checks and console/restore access; capture both successful and failed behavior.

1. Two-distribution baseline: inventory a Debian-family and an RPM-family VM: boot/kernel, architecture, devices, filesystems, packages, network owner, systemd and security controls. Success: explain at least five command/configuration differences and distinguish runtime from persistent state; negative case: a command absent on one distribution. Record versions and restore points.
2. Storage/recovery: attach only disposable labeled disks, verify identity, partition/format/mount by UUID and practice LVM growth. Archive and restore synthetic data to a separate location, checking bytes plus the metadata the workload needs. Success: evidence confirms block/LV/filesystem sizes independently; recover one deliberate noncritical mount fault through console. Do not run repair or destructive tests on existing data.
3. Identity/services: create test users/groups, directory setgid/sticky behavior, a named ACL and mask, and a service/timer. Test permitted and denied access, password-lock versus alternate access, runtime/enabled state and a missed calendar activation. Success: effective policy and logs match expectations after restart/reboot; remove only the lab identities/artifacts after transferring any owned test files.
4. Network/firewall: configure a private interface and test service through the distribution’s owning tools. Record address, route, resolver, socket and IPv4/IPv6 policy; test permitted and denied traffic. Success: distinguish a name-resolution fault from a transport/service fault and verify persistent configuration with console rollback available.
5. Hardening: validate a narrow sudo/SSH policy, inspect authentication/audit records and exercise a supported SELinux/AppArmor adjustment. Verify a package against vendor advisory/backport evidence and record a scanner exception only when justified. Success: the required operation works while an unauthorized path remains denied; no blanket enforcement disablement or generic PAM-stack replacement.
6. Containers/virtualization: build a non-root container with a pinned image, scoped volume/network and resource limits; recreate it to test data persistence. Compare the container’s writable layer with a volume and a VM snapshot with a separately retained backup. Success: authorized access/data survives the intended lifecycle and one denied path remains blocked; clean up only the disposable resources.
7. Automation/code: run the original shell and restore-comparison exercises, including negative inputs and producer failure. In real Linux VMs, add a reviewed idempotent configuration task and version it with Git; resolve a controlled merge conflict and retest. Success: evidence separates script syntax, repeated execution, correct desired state and rollback. Treat AI-generated code as a draft requiring source/version and data-governance review.
8. Break/fix capstone: inject one safe service, mount, resolver, permission and resource-pressure fault at a time across restore points. Capture a baseline, discriminating test, narrow fix and recovery proof. Success: explain root cause with time-aligned evidence, verify direct/dependent/security behavior and document prevention; do not equate high load or one log line with a complete diagnosis.

Original knowledge checks

1. What are the major Linux boot boundaries and their best evidence?
2. Why can a working runtime change still fail after reboot?
3. What is the difference between /proc, /sys, /dev and /run?
4. How do module load-now and load-at-boot differ?
5. Distinguish partition table, partition, filesystem and mount point.
6. How do PV, VG and LV relate in LVM?
7. Why are RAID and snapshots not automatically backups?
8. What must be proven before editing a critical fstab entry?
9. How do df and du answer different capacity questions?
10. Why can a host with a valid IP still lack application connectivity?
11. Which shell expansion and path hazards make bulk commands dangerous?
12. How do VM bridge, NAT and isolated networks differ?
13. What do read/write/execute mean on a directory?
14. Distinguish hard and symbolic links.
15. How do ACL masks, mode bits and mandatory-access-control rules contribute to effective access?
16. What must account offboarding do beyond deleting /etc/passwd entry?
17. What creates a zombie process, and why is killing the zombie itself ineffective?
18. Which context must a scheduled job define explicitly?
19. Why is enabling an unsigned repository a security and operations risk?
20. Distinguish active, enabled, masked and failed systemd unit state.
21. What is the difference among reload, restart and daemon-reload?
22. Why does missing log evidence not prove no event occurred?
23. Distinguish image, container writable layer and volume.
24. Why should a container avoid privileged/root execution?
25. What makes PAM change capable of locking out administrators?
26. Which controls belong in secure SSH administration?
27. Why must firewall changes be tested for persistence and IPv6?
28. How does SELinux/AppArmor evidence differ from Unix permission evidence?
29. Where can automation secrets leak on Linux?
30. What does a compliance scan fail to prove?
31. How does idempotence differ from correctness?
32. Which safety properties belong in a shell script?
33. Why use a Python virtual environment?
34. What must happen after a Git merge conflict is resolved?
35. Which controls make AI-assisted code use responsible?
36. What is the troubleshooting sequence?
37. Which evidence separates full blocks from full inodes or deleted-open files?
38. How would you isolate DNS from service failure?
39. Why can a successful systemctl is-active result coexist with an outage?
40. Which evidence separates CPU, memory, I/O and network bottlenecks?
41. What makes a Linux change complete?

42. What exactly is announced about XK0-006 retirement?

43. What does requested mode 0666 with umask 0003 produce, and what changes with a default ACL?

44. Does a persistent calendar timer replay every missed interval or restart an already active service?
45. Which important preservation properties are not included by rsync archive mode alone?
46. Why can a failed producer be hidden by a pipeline, and what does pipefail change?

Answers and reasoning

1. Firmware, bootloader, kernel/initramfs, PID1/units and application; use console, config, kernel/journal and unit/app logs.
2. It may not update the owning persistent configuration or generated boot state.
3. Process/kernel view, device/kernel object view, device nodes and transient runtime state respectively.
4. modprobe changes current state; boot configuration/initramfs/module rules determine recurrence.
5. Disk layout metadata, allocated region, on-disk file organization and directory attachment.
6. Disks/partitions become PVs, PV capacity forms a VG, and LVs allocate from the VG for filesystems/swap/use.
7. They can share corruption, deletion, controller/site/credential failure and lack independent tested retention.
8. Correct device/UUID/filesystem/options/path, backup/console rollback and a safe mount test.
9. df reports filesystem allocation/inodes; du totals reachable directory entries and can miss deleted-open space.
10. Route, DNS, firewall, socket, TLS, identity, service, dependency or return path can still fail.
11. Unquoted whitespace/globs/newlines, leading hyphens, symlinks, recursion, mount crossing, privilege and empty/wrong selections.
12. Layer-2 attachment, translated host-mediated access and no external attachment.
13. List names, create/delete/rename entries, and traverse/access metadata (with combinations/ownership considered).
14. Another inode name on the same filesystem versus a path reference that can cross filesystems or dangle.
15. The ACL mask limits named-user/group-class entries, and extended-ACL group mode bits correspond to that mask. Owner/other entries have their own role; MAC, path traversal, mount and application restrictions also apply.
16. Revoke sessions/keys/tokens/jobs/privilege, handle files/processes/data, preserve audit and document ownership transfer.
17. A child exited but its parent has not reaped status; fix/restart the parent rather than signaling an already-dead child.
18. Identity, environment/PATH, working directory, inputs, concurrency, schedule/missed run, output/logging and failure notification.
19. It expands trusted code/supply chain, can replace dependencies and may be unsupported across upgrades.
20. Running now, linked for automatic start, prevented from starting, and last attempt failed.
21. Re-read service configuration in-process, stop/start process, and make systemd reread unit definitions.
22. Wrong source/query/time, rotation, permissions, rate limit, forwarding or logging failure can hide it.
23. Immutable template, ephemeral runtime changes and separately managed persistent data.
24. It expands host/device/kernel/capability impact if the workload or image is compromised.
25. Module order/control flags affect every authentication/session; keep a tested session and recovery path.
26. Supported crypto, host verification, protected keys, restricted users/sources, least privilege, MFA/jump path, logs and recovery.
27. Runtime rules can disappear and a parallel IPv6 path can remain open or blocked differently.
28. Look for AVC/profile denials and labels/policy/path rules in addition to UID/GID/mode/ACL.
29. Arguments/process list, environment, shell history, files/repos, templates/state, logs, artifacts and images.
30. Actual exploitability, business context, every control, sustained operation or absence of unknown weaknesses.
31. Repeatable convergence can consistently deploy the wrong or unauthorized state.
32. Quoting, validated input/target/privilege, explicit errors/status, safe temporary files, logs, idempotence/dry-run and rollback.
33. Isolate application dependencies from system packages and make versions reproducible.
34. Review the semantic result, run tests/security checks and preserve a comprehensible history.
35. Sanitized inputs, no secrets, current-source verification, human review, tests/scans, isolated execution and accountable approval.
36. Define/scope/baseline, theorize, discriminate safely, plan/approve/rollback, change one variable, validate/reboot, document/prevent.
37. df blocks/inodes, du, lsof for deleted-open files, quotas and exact mount identity.
38. Compare resolver output and name test with direct IP/socket/local service tests and authoritative/cache evidence.
39. Process existence does not prove socket, firewall, dependency, configuration, authentication or correct response.
40. Time-aligned run queue/CPU, memory/swap/pressure, device latency/queue/throughput and loss/latency/socket/flow evidence.
41. Runtime and persistent state, direct/dependent/security/log behavior, restart/reboot/recreate, rollback/backup and documentation.
42. No exact date; the page says usually three years after launch and estimates 2028. Document 5.0 is not a new exam-series announcement.
43. 0664 through bit clearing, not arithmetic subtraction. With a parent default ACL, inheritance and the requested mode determine creation permissions instead of the ordinary umask calculation.
44. Persistent calendar timers can catch up after inactivity, subject to timing rules; they do not create one job per missed interval. An already active target service is not restarted just because the timer elapses.
45. In particular ACLs, extended attributes and hard-link relationships need separate options/capability checks; archive mode alone does not establish a complete restore or application-consistent backup.
46. By default the last stage determines pipeline status. Bash pipefail makes the rightmost nonzero stage determine failure; partial output can still exist and must not be accepted as complete.

XK0-005-to-XK0-006 gap checklist

Map older material line by line to V8 and current distributions. Verify current boot/kernel/device/storage/network/backup/virtualization workflows; systemd services/logs/timers and containers; PAM/LDAP/Kerberos/audit/MFA; nftables/firewalld/UFW ownership alongside legacy iptables concepts; SSH, SELinux/AppArmor, cryptography/integrity/compliance; explicit Ansible/Puppet and CI/CD concepts; Bash and Python environments/packages/data types; Git workflows/tagging; responsible AI code generation/prompt handling; and the reweighted troubleshooting coverage across boot/mount, firewall/routing/DNS, MAC/permissions/vulnerability and CPU/memory/I/O performance. Do not copy a distribution-specific command without verifying its release, owner and persistent configuration path.

Source and freshness notes

• CompTIA controls the V8 domains, weights, delivery, score/language, experience guidance and estimated lifecycle.
• Distributions, kernels, packages, commands, configuration ownership, security guidance, automation tools, container runtimes and cloud behavior change. Verify against the current distribution/product documentation and local man/info/--help output.
• This guide contains original scenarios, labs, checks and explanations synthesized from public scope. It does not reproduce proprietary objectives, PBQs, course labs or recalled exam items.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

October 29, 2026 current-source update

The upstream kernel archive listed mainline 7.3 dated October 18 and stable 7.2.13 dated October 26. These are upstream release examples, not Linux+ objectives or a promise about a distribution’s supported kernel. When investigating a host, record uname -r, identify the distribution package/build, then check that vendor’s security advisory and backport status before calling a finding fixed or vulnerable. Related item: the Linux Foundation’s free Introduction to Linux (LFS101) is a broad foundations refresher, not a complete XK0-006 path; the page publishes no duration, so any study time is an author estimate.

Places to learn

This is not a complete list and is not meant to be consumed in full. Choose one current XK0-006 path, spend at least as much time operating and breaking/fixing disposable Linux systems as watching, and use one explanation-led assessment for remediation.

Resource	Access	Estimated time
CompTIA CertMaster Perform, Learn, Labs, and Practice	Paid official platform; select exact XK0-006 product/bundle	Provider estimates: Perform 30–60h, Learn 25–40h, Practice 10–20h, Labs 15–25h; overlapping options, not additive requirements
Pluralsight Linux+ path	Subscription; 5 courses, 4 labs and practice exam listed; course and lab dates vary	27 listed hours plus 35–70 suggested additional lab/review hours
LinkedIn Learning / Total Seminars XK0-006	Subscription; Total Seminars V8 course released March 18, 2026; 10 quizzes	15 hours 42 minutes listed plus 35–70 suggested lab/review hours
Linux Foundation Introduction to Linux (LFS101)	Free foundation course; registration required for lessons; no provider duration published	About 15–25 hours for selected foundations and independent practice (author estimate); not full XK0-006 coverage
O'Reilly/Sybex Linux+ Study Guide	Subscription book; automated catalog access blocked; prior sixth-edition claim not reverified	Suggested 25–45 reading hours plus 35–70 lab/review hours; verify current edition
Udemy / Jason Dion XK0-006	Paid marketplace course; automated catalog access blocked	Earlier 34h39 runtime not reverified; inspect current syllabus/revision
MeasureUp XK0-006 CertKit	Paid course bundle, exam simulation and Online Mentor listed; different access periods	Suggested 35–70 selected learning/practice hours; listed e-learning 365 days and practice 60 days from first practice access; verify terms

VERIFY CURRENT: Public metadata checked September 29, 2026; paid interiors, question banks and provider labs were not accessed. Pluralsight courses are dated March/April 2025 and its four labs April–August 2026; newer lab dates do not re-date every lesson. The 27-hour path estimate already includes listed path content. Extra study-hour ranges are planning judgments, not provider guarantees. No exact current Whizlabs XK0-006 route or established complete free creator course was independently selected during this review. Reject “actual questions,” dumps and copied destructive commands. Provider duration, bundle, practice bank, revision, price and access details are volatile.