RoleMath Study Track · free study companion
A free study companion keyed to the officially published exam domains of CompTIA Linux+ (XK0-006): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. CompTIA Linux+ objectives
A free, source-cited study companion built on CompTIA's published XK0-006 objectives — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Not sure which domain to start with? Take the readiness check on the cert page →
Program blueprint under review
A free Linux+ program blueprint pinned to current XK0-006, turning system management, services/users, security, automation, and troubleshooting into reproducible evidence inside a risk-controlled disposable Linux environment without claiming instructional completeness or an exam or employment outcome.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Choose an outcome
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Learners targeting XK0-006 who have general IT foundations and need one hands-on sequence across all five current Linux+ domains.
Completion emphasis: Complete all modules and safe VM labs, the integrated service-host capstone, a command/objective crosswalk, and a final gap review against the official page.
Support, cloud, operations, and career-change learners who want reviewable command, configuration, service, security, automation, recovery, and handoff evidence.
Completion emphasis: Retain sanitized inventory, users/groups/permissions, services, network/storage, security, script/schedule, logs, faults, backup/restore, change/rollback, and administrator-handoff artifacts.
Learners deciding whether terminal-based systems, cloud operations, platform engineering, or DevOps-style work fits their interests and current foundation.
Completion emphasis: Complete the diagnostic plus navigation/process/service, user/permission, security, script, and fault-recovery labs; record whether to continue, build foundations, or choose another operations route.
Start safely
Verify current version, general IT foundation, disposable environment, command safety, and recovery practices before intermediate Linux administration; this is not a formal prerequisite or pass prediction.
Ready when: Yes, typically through equivalent A+/Network+ knowledge or prior general IT practice.
If not yet: Build general support and networking foundations before treating Linux+ as the next exam target.
Ready when: Yes, with a local VM preferred for systemd, service, firewall, user, package, and fault exercises.
If not yet: Use sanitized command/output transcripts for active-change labs and label them observation-only; WSL/browser shells may not support every systemd or service step.
Ready when: Yes, with every destructive-looking command limited to a specific practice path or disposable VM.
If not yet: Complete the pwd/ls/cd/touch/cp/mv/mkdir permission warm-up and use echo-only command previews before sudo, rm, package, firewall, or service changes.
Ready when: Yes, with snapshot restore and file restore tested before deliberate faults.
If not yet: Do not perform active configuration/fault steps; use written alternatives until rollback is proven.
Ready when: Yes, using fictional users, throwaway passwords, private/NAT networking, and no sensitive mounts.
If not yet: Remove shared mounts and real credentials or stay on the observation-only route.
Ready when: Yes, with CompTIA's recommended experience treated as useful context even though no formal prerequisite is invented.
If not yet: Choose the steady pace or complete a Linux fundamentals month before scheduling an intermediate exam.
Plan, then adapt
14 weeks 8-10 hours/week
A planning estimate for learners building their first sustained Linux practice: separate setup, system management, users/services, security, automation, troubleshooting, and capstone recovery.
10 weeks 10-14 hours/week
A planning estimate that covers one administration domain most weeks and reserves two weeks for the integrated host, contained faults, restore, handoff, and gaps.
6 weeks 16-20 hours/week
For learners with existing Linux administration, cloud operations, or equivalent lab experience; do not compress unfamiliar storage, security, service, scripting, or recovery work.
Evidence-gated sequence
Pin XK0-006, assess foundations, build or select a disposable Linux environment, prove snapshot/config recovery, and establish command/evidence rules.
Navigate and inspect the Linux system, manage software and process/service state, and record storage/device/configuration evidence without broad or destructive changes.
Modules: System Management
Create and verify fictional identities, group-controlled files, service state, authentication, resource limits, and lifecycle cleanup in the disposable VM.
Modules: Services and User Management
Harden access and service exposure, protect credentials/data, inspect security state, and verify controls inside the snapshot-backed VM.
Modules: Security
Automate a safe administration task with inputs, conditions, loops, functions, logging, exit status, idempotence, validation, scheduling, and cleanup while recognizing configuration/container concepts.
Modules: Automation, Orchestration, and Scripting
Diagnose contained boot/service/process/storage/network/permission/resource issues through baseline comparison, logs, least-destructive tests, backups, fixes, and verified recovery.
Modules: Troubleshooting
Build, secure, automate, monitor, break, recover, and hand off a fictional Linux service host inside a disposable VM with reproducible evidence across all five domains.
Modules: System Management, Services and User Management, Security, Automation, Orchestration, and Scripting, Troubleshooting
Before a lab
Show your work
Completing this policy demonstrates XK0-006 coverage and disposable-VM practice inside RoleMath; it does not predict a Linux+ score, replace recommended experience, or establish professional Linux administration.
Integrated practice
Provision and document a fictional Linux service host inside a snapshot-backed VM, establish users/services/security/automation/monitoring, introduce contained faults, recover from file and snapshot backups, and leave a reproducible administrator handoff across all five Linux+ domains.
Safety boundary: Perform active work only inside a personally owned disposable VM with a local console, named snapshots, specific configuration backups, private/NAT networking, fictional users/secrets, and no sensitive host mounts. Verify user, privilege, exact path/device, expansion, effect, rollback, and output before every change. Never run broad destructive commands or alter a host, remote access path, work/shared system, or production service.
Finish honestly
Present the artifacts as self-directed XK0-006 disposable-VM lab work. Do not call them production administration, professional Linux experience, official CompTIA labs, job readiness, or a RoleMath credential.
Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 60 days.
The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. CompTIA Linux+ objectives
Linux+ is an intermediate certification: CompTIA recommends roughly 12 months of hands-on Linux experience and, for many career changers, earning A+ and Network+ first to build general IT footing before attempting it. Assuming you have that grounding, our default sequencing advice is heaviest-weight-first, because the published weights tell you where the exam spends its questions. That gives: System Management (23%) first, then Troubleshooting (22%), then Services and User Management (20%), then Security (18%), then Automation, Orchestration, and Scripting (17%). There is one honest dependency wrinkle worth naming: Troubleshooting is a capstone skill — you diagnose a system faster once you already know how it is managed, what services and users it runs, and how it is secured. By pure weight it comes second, and you can study it second to respect the weights, but do not expect it to fully click until the later domains have filled in; it is normal to loop back to it at the end. Automation sits last by weight and also builds naturally on everything before it, since a script mostly automates tasks the earlier domains taught you to do by hand. This is sequencing advice based on the published weights and how the topics depend on each other, not a claim about the science of learning — if a different order fits how you think, use it.
Module 1 of 5 · domain 1 · 23% of the exam
Start here. At 23% it is the heaviest domain, and it is the everyday foundation — the filesystem, packages, processes, and the systemd service manager — that every other domain quietly assumes you can already navigate from a terminal.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Linux+ objectives
This is the heaviest domain at 23%, and it is the 'live in the system from a terminal' domain. Before Linux+ asks you to run services, secure a host, script tasks, or diagnose a failure, it expects you to be fluent in the daily fabric of a Linux machine: moving around the filesystem, installing and inspecting software, watching processes, and managing the modern service manager that starts almost everything on a running system. Almost every scenario elsewhere on the exam is written in the commands and concepts this domain teaches, so if a later question ever feels like a foreign language, the gap is usually right here. For a career changer coming from a Windows or point-and-click background, this is the domain where the command line stops being intimidating and starts being home.
The first pillar is the filesystem and how Linux organizes everything as files under a single tree rooted at slash. You are expected to know your way around the standard layout — where configuration lives, where system binaries live, where logs and temporary files go, where a user's home sits — and to move, copy, create, and inspect files and directories with confidence. Just as important is understanding what a path means, the difference between absolute and relative paths, and how Linux treats devices, mounted disks, and even much of the kernel's live state as files you can read. The mental model to build is that in Linux almost everything is a file, and knowing where a file belongs is half of knowing what it does.
The second pillar is software management through package managers, which is how Linux installs, updates, and removes programs cleanly rather than hunting for installers. The two big families you should recognize are the Debian and Ubuntu world (using apt on top of dpkg packages) and the Red Hat and Fedora world (using dnf on top of rpm packages). The concepts that carry across both are repositories — trusted online catalogs your system pulls software from — and dependency resolution, where the package manager works out and installs the other pieces a program needs. Knowing which family a system belongs to, and the equivalent command in each, is a recurring exam and on-the-job skill, because a Linux administrator rarely gets to choose only one distribution.
The third pillar is processes: the running programs that make up a live system. You should understand that every process has an identifier and a parent, that processes have states and priorities, and that you can list them, find the ones consuming resources, adjust their priority, and stop a misbehaving one by sending it a signal. The related idea of running work in the foreground versus the background, and keeping a job alive after you log out, belongs here too. Seeing the system as a shifting population of processes rather than a static box is the shift in thinking this pillar rewards, and it is the direct precursor to the troubleshooting domain, where a runaway process is a classic culprit.
The fourth pillar is systemd, the init system and service manager that modern mainstream distributions use to boot the machine and manage long-running services. This is where you learn to start, stop, enable (so it launches at boot), disable, and check the status of a service through a single consistent tool, and to understand the unit files that describe each service. Systemd also governs targets (the rough equivalent of the old runlevels that define what state the system boots into) and ties into the system journal for logs. Because nearly every service in the later domains is started and supervised by systemd, comfort with it here pays off everywhere downstream — it is arguably the single most leveraged skill in the whole track.
The way to study this domain is to stop reading and start living in a shell, which is exactly what the lab below sets up: you get a genuinely free Linux environment and then navigate the filesystem, inspect packages, watch processes, and query systemd with your own hands. As you work, narrate what each command shows you — where am I, what is installed, what is running, what is systemd supervising — until moving around the system is automatic. And read the official CompTIA Linux+ objectives page for the exact topic list; this explanation deliberately paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Get a genuinely free Linux environment running, then use it to make the four pillars of this domain concrete: navigate the filesystem tree, inspect installed packages, watch live processes, and query the systemd service manager. This is the command-line comfort every other domain assumes, built with your own hands on a system you own.
A working Linux prompt in a free environment you own; the filesystem tree listed from '/' with config in /etc and logs in /var/log; a list of installed packages and where one of them came from; a live, updating view of running processes with their IDs and resource use; and systemd reporting which services are running, whether one is enabled at boot, and the unit file that defines it. The command line has stopped being a mystery and become a place you can navigate.
This lab practices the filesystem navigation, package management, process management, and systemd service-management skills that Domain 1 (System Management) of the official XK0-006 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: Do everything inside a Linux environment you own — your own WSL install, your own VirtualBox VM, or a free browser-based shell. Never run these commands on a shared, work, or school system you do not control. The listing, viewing, and status commands here are read-only and safe. Never run destructive commands such as 'rm -rf /' or 'rm -rf' against broad paths; the only removal in this lab targets one specific file you just created in your own home directory. When in doubt, prefer a throwaway VM you can simply delete and rebuild.
3RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 5 · domain 5 · 22% of the exam
Second in our suggested order by weight (22%), but a capstone in spirit — you diagnose a system faster once you already know how it is managed, run, and secured. Study it second to respect the weight, but expect to loop back to it after the later domains fill in.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Linux+ objectives
This is the second-heaviest domain at 22%, and it is the capstone: it takes everything from the other four domains and asks you to use it when something is broken and someone wants it fixed. That is the honest tension in its placement — by weight it comes second, but you diagnose a Linux system fastest once you already understand how it is managed, what services and users it runs, and how it is secured, so it is normal to study it second and then loop back once the later domains have filled in. It is also the most job-shaped domain on the exam, because diagnosing and fixing problems is a large share of what real Linux administration, cloud, and DevOps work actually is.
The backbone of the domain is a disciplined approach — a repeatable way of narrowing a problem instead of guessing. The habit worth internalizing is a loop: gather the symptoms and ask what changed, form a specific theory of the probable cause, test that one theory, act on it if confirmed, verify the system truly works again, and record what you found and did. The whole point is to replace flailing with a sequence that eliminates possibilities one tested theory at a time. On Linux this is especially powerful because the system is so transparent — almost every subsystem will tell you what is wrong if you know which file, log, or command to ask.
The single most important skill is reading logs, because a healthy Linux system narrates its own failures. On modern systemd-based distributions the central tool is journalctl, which queries the system journal — you can filter by service, by time window, by priority, and follow logs live as a problem happens. Alongside it live the traditional text logs under /var/log for services that write there. The exam-and-job skill is not memorizing every log path; it is the instinct to go to the logs first and to read an error message as a lead rather than a dead end. 'What does the log say?' is the most productive question in Linux troubleshooting, and it is exactly what this domain's lab drills.
A powerful lens for organizing the search is to think in subsystems, the same way the earlier domains carved up the machine. Is this a storage problem (a full disk, a filesystem that will not mount, permissions denying access)? A process or service problem (a unit that failed to start, a process consuming all the memory or CPU)? A network problem (no address, no route, name resolution failing)? A user or permission problem (an account that cannot log in, a file a service cannot read)? Isolating which subsystem a fault lives in collapses a huge search space into a small one. 'The service will not start' sends you to its status and logs; 'the disk is full' sends you to storage tools; each symptom points at a subsystem and its tools.
The domain then expects fluency with the diagnostic toolkit, most of which is already on every system. Service and process inspection through systemctl, journalctl, ps, and top; storage diagnosis through df (free space), du (what is using it), and the mount and filesystem tools; network checks through the ip, ss, ping, and name-resolution commands; and permission and ownership readouts. Crucially, the exam cares less about whether you can type a command than whether you can interpret its output — what a failed unit's status is telling you, what a disk at 100% means for a service that cannot write, what a permission-denied error reveals about ownership. Pattern recognition matters here: the faster you match a set of symptoms to a familiar cause, the faster you reach a tested theory rather than a guess.
The best way to study this domain is to practice the loop on a service you deliberately break and then fix, which is exactly what the lab below does: you read logs with journalctl, diagnose a service that will not start, and walk the isolate-test-verify sequence on your own system. Combine that with narrating your reasoning out loud — symptom, theory, test, result, next step — until it is automatic under pressure. And read the official CompTIA Linux+ objectives page for the exact topic list and its statement of the approach; this explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Walk the troubleshooting loop on a real service using only built-in tools: read the system journal, deliberately break a service in a safe and reversible way, diagnose why it will not start by reading its status and logs, then fix it and verify. This is the isolate-test-verify discipline made concrete on a system you own.
The system journal readable and filterable by errors and by service; a service that visibly fails to start after you introduce a bad config line; a status output and a 'journalctl -u' log that point straight at the offending line; a config-test command that names the exact error; and the service returning to 'active (running)' after you restore the config and verify it. You have run the full troubleshooting loop — symptom, theory, test, fix, verify, document — on a live service.
This lab practices the log-analysis (journalctl), service-diagnosis, and methodical isolate-test-verify approach, plus the storage and process checks, that Domain 5 (Troubleshooting) of the official XK0-006 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: Do this only on a Linux environment you own — a throwaway VirtualBox VM is ideal because you deliberately break a service. If you are working over SSH on a remote machine, do NOT break the SSH service you are connected through, or you may lock yourself out; use a local console or a different practice service instead. Always back up a config file before editing it (this lab does), and restore from that backup to recover. Never run destructive commands like 'rm -rf' against broad paths, and never break services on shared, work, or production systems.
3RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 5 · domain 2 · 20% of the exam
Third in our suggested order, at 20%. Once you can navigate the system and drive systemd from Domain 1, this domain is where you create the users a system serves and run the services it exists to provide — with permissions as the connective tissue between them.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Linux+ objectives
This is the 'who uses the system, and what does it serve' domain, and at 20% it is a substantial slice. It joins two closely related jobs a Linux administrator does constantly: managing the accounts and groups that identify the people and programs using a machine, and running the services — web servers, databases, name resolution, scheduled jobs — that the machine exists to provide. The connective tissue between them is the permission model, which decides which users and services are allowed to touch which files. For career changers this domain is very tangible: you are literally creating accounts and turning services on, which makes the abstract idea of 'administering a system' finally concrete.
The foundation is users and groups. Every account on a Linux system has a numeric user ID and belongs to one or more groups, and the system records these in a small set of well-known files (the account list, the group list, and the shadow file that holds password hashes). You are expected to be able to create, modify, and remove users and groups; understand the difference between an ordinary user, a system account that a service runs as, and the all-powerful root; and set a user's home directory and login shell. The exam wants you to reason about accounts as the identities that everything else grants or denies access to — the same 'least privilege' instinct that runs through the security domain starts here, in not handing out more account power than a person or service needs.
Closely tied to accounts is the permission model, which is where a lot of Linux's day-to-day security lives. Every file and directory has an owner, a group, and three sets of read/write/execute permissions — for the owner, the group, and everyone else — and you should be fluent reading and setting them both in symbolic form and as the numeric (octal) triples that appear everywhere in documentation. Beyond the basics sit the special permission bits and the mechanisms for granting carefully scoped administrative power, most importantly running a single command as another user through sudo rather than logging in as root. Understanding permissions well enough to explain why a service cannot read a file it needs is one of the most reused troubleshooting skills there is.
The other half of the domain is services in the substantive sense: the software that makes a server useful. You are expected to be familiar with the common categories and be able to recognize, install, and control them — web servers that answer HTTP requests, database servers that store structured data, name resolution and address-assignment services on the network side, mail and file-sharing services, and the print or logging services that support them. You do not need to master the configuration of every one, but you should know what each category is for and how to start, stop, and enable it. Because Domain 1 already taught you systemd, controlling a service here is a familiar motion applied to new software.
A recurring theme is that services run as accounts, which is exactly where this domain's two halves meet. A well-configured web or database server does not run as root; it runs as a dedicated, low-privilege system account so that if the service is compromised, the damage is contained. Scheduling belongs here too — the ability to run a task automatically on a timetable, whether through the classic cron scheduler or a systemd timer — because so much routine service work (backups, cleanup, report generation) is scheduled rather than run by hand. Seeing accounts, permissions, and services as one interlocking system, rather than three separate topics, is the maturity this domain is checking for.
The way to study this domain is to create an account and stand up a permissioned resource with your own hands, which is exactly what the lab below does: you add a user, set group-based file permissions, and start and enable a service, watching how identity and access fit together. As you work, keep asking the two questions this domain lives on — who is this user or service, and what is the least access it needs? And read the official CompTIA Linux+ objectives page for the exact topic list; this explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Join the two halves of this domain by hand: create a new user and a shared group, use permissions to control who can read a directory, then start and enable a real service and confirm it is running. You will feel how identity, permissions, and services interlock — the everyday motion of administering a Linux host.
A new user 'alice' with a home directory, a login shell, and membership in a group you created; a shared directory whose permissions (770) let the owner and group in but keep everyone else out, readable in the 'ls -ld' output; and a real service that reports 'active (running)', is enabled to start at boot, and runs under a system account rather than your personal login. Identity, permissions, and services have clicked into one picture.
This lab practices the user and group management, file-permission, and service-control skills that Domain 2 (Services and User Management) of the official XK0-006 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: Run this only on a Linux environment you own (your WSL install or a throwaway VM). Creating users, setting permissions, and installing a service all use administrative rights, so a mistake on a shared or production system could lock people out or expose a service — never do this on a machine you do not control. Every 'rm' in this lab targets one specific path you created; never run 'rm -r' or 'rm -rf' against broad or system paths. Give the practice user a throwaway password and remove it when you finish.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 5 · domain 3 · 18% of the exam
Fourth in our suggested order, at 18%. It applies the accounts, permissions, and services from the earlier domains with an adversary in mind — hardening access, filtering the network edge, and protecting data — and it is a natural bridge toward Security+ afterward.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Linux+ objectives
This is the 'keep the system from being abused' domain, and at 18% it is a meaningful slice that also serves as a natural bridge toward a security-focused path like Security+ afterward. Where the earlier domains taught you to manage, run, and serve a Linux host, this one asks how you defend it: hardening the ways people and programs get in, controlling what traffic reaches the machine, protecting data at rest and in transit, and layering the mandatory-access controls that contain a compromise. A lot of it is Domains 1 and 2 revisited with an adversary in mind — permissions, accounts, and services all become security surfaces here.
The starting point is access hardening, and the most important everyday tool is secure remote access over SSH. You are expected to understand how SSH lets you administer a machine over an encrypted channel, and — crucially — why key-based authentication is stronger than passwords: a keypair proves identity with a secret that never travels over the wire and cannot be guessed by brute force. Around that sit the hardening habits: disabling direct root login over SSH, preferring keys over passwords, changing or restricting where a service listens, and removing or disabling accounts and services you do not need. The instinct to reduce the attack surface — fewer open doors, fewer privileged accounts — is the through-line of the whole domain.
The network edge is the next layer: the host firewall that decides which traffic is allowed to reach the machine at all. You should recognize the common front-ends — the uncomplicated firewall (ufw) on Ubuntu-style systems and firewalld on Red Hat-style systems — and understand that both sit on top of the kernel's packet-filtering machinery. The concept the exam wants is default-deny thinking: allow only the specific services you intend to expose (say, SSH and a web port) and block the rest, so a service you forgot about is not silently reachable. This connects directly to the services domain — every service you start is a door, and the firewall decides whether that door is open to the network.
Data protection is the third strand: keeping information confidential and intact whether it is sitting on disk or moving across a network. On the disk side this includes filesystem and full-disk encryption so that a stolen drive does not surrender its contents, and the use of hashing and checksums to prove a file has not been tampered with. In transit, it is the encrypted channels — SSH and TLS — that protect data as it travels. The exam expects you to reason about which protection applies to a described situation: 'the laptop was stolen' points to disk encryption, while 'the data is intercepted on the network' points to encryption in transit.
The final layer is mandatory access control and broader hardening — the systems that go beyond ordinary file permissions to confine what a process can do even if it is running as a powerful account. The two you should recognize by name and purpose are SELinux (prominent on Red Hat-family systems) and AppArmor (prominent on Ubuntu-family systems); both enforce policies that constrain programs to only the resources they legitimately need, so a compromised web server cannot roam the whole filesystem. Alongside them sit auditing and logging (keeping a trustworthy record of security-relevant events) and the general discipline of patching promptly, all of which the exam frames as defense in depth: no single control is trusted to be perfect, so you stack several.
The best way to study this domain is to harden a real host with your own hands, which is exactly what the lab below does: you generate an SSH keypair, use key-based login, and inspect (and reason about) the host firewall. Doing it makes the case for keys over passwords and default-deny firewalling far more convincingly than any list of terms. As you study, keep asking the defender's questions — which security goal does this protect, what attack does this stop, and what can an attacker who gets one foothold still reach? And read the official CompTIA Linux+ objectives page for the exact topic list; this explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Practice the two most reused Linux security habits by hand: generate an SSH keypair and understand why key-based authentication beats passwords, then inspect your host firewall and reason about default-deny rules. You will make access hardening and edge filtering concrete on a system you own.
A generated SSH keypair with a locked-down private key and a shareable public key you can read; an understanding, made concrete, of why proving you hold a private key beats sending a password; the SSH server's hardening settings you can reason about; and a host firewall whose status you can read, allowing only named services while denying the rest. Access hardening and edge filtering are no longer abstract.
This lab practices the secure-remote-access, SSH-key, and host-firewall skills that Domain 3 (Security) of the official XK0-006 objectives covers, building on the accounts and services of Domain 2 — see the official objectives page for the exam's own wording.
Stay safe & legal: Do this only on a Linux environment you own. Generating keys and reading firewall status are safe and mostly read-only. Be careful enabling a firewall on a remote or headless machine: always allow SSH before enabling the firewall, or you can lock yourself out — this is why the enable step is optional and reserved for a throwaway VM. Keep your private key private and never paste real production keys or credentials into a practice environment. Do not point any of this at a system you do not own.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 5 of 5 · domain 4 · 17% of the exam
Last in our suggested order, at 17% — the lightest domain, and the one that builds most directly on everything before it, since a script mostly automates tasks the earlier domains taught you to do by hand. It is also the clearest on-ramp to a DevOps path.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Linux+ objectives
This is the 'stop doing it by hand' domain, and at 17% it is the lightest of the five — but for a career changer aiming at cloud or DevOps work, it may be the most career-defining, because automation is what separates a Linux user from a Linux engineer. It covers writing scripts to automate repetitive tasks, scheduling work to run on its own, using version control to track changes, and the higher-level ideas of configuration management, containers, and infrastructure as code. It sits last in our suggested order for a good reason: a script mostly automates the very tasks the earlier domains taught you to do by hand, so it lands best once those are familiar.
The foundation is shell scripting, and specifically bash — the default shell on most Linux systems. A shell script is simply a text file of commands the shell runs in order, but the exam expects you to go a step further into real programming constructs: variables to hold values, conditionals to make decisions ('if this file exists, do that'), loops to repeat work over a list, reading input and arguments, and exit codes to report success or failure. The mindset shift is from typing one command at a time to describing a whole procedure once, so it runs identically every time. Even modest scripting — a backup routine, a log-cleanup job, a health check — pays for itself quickly and is exactly what employers mean when they ask for automation skills.
Scheduling is the natural partner to scripting, because a script's value multiplies when it runs on its own. The classic tool is cron, which runs commands on a fixed timetable defined by a compact five-field schedule (minute, hour, day of month, month, day of week); the more modern alternative is a systemd timer. Either way, the concept the exam wants is unattended, repeatable execution: backups that happen every night, reports that generate every Monday, cleanup that runs every hour, all without a human remembering to start them. Combining a script you wrote with a schedule you set is the smallest complete unit of real automation, which is exactly why this domain's lab has you build both.
Version control, centered on Git, is the next strand — the discipline of tracking changes to files (scripts, configuration, infrastructure definitions) over time so you can see what changed, when, and why, and roll back when something breaks. You are expected to understand the everyday flow: putting files under version control, saving snapshots as commits with messages, viewing history, and working with remote repositories that teams share. For anyone heading toward DevOps this is not optional background; it is the substrate that modern infrastructure work runs on, because in a mature shop even the servers themselves are described in versioned text files.
The domain then rises to the orchestration and infrastructure ideas that give it its name. Configuration management tools apply a desired state to many machines consistently, so a fleet of servers ends up identically and correctly set up without hand-configuration. Containers package an application with its dependencies so it runs the same everywhere, and container orchestration coordinates many of them across many hosts. Infrastructure as code describes the servers, networks, and services themselves in text files that can be reviewed, versioned, and rebuilt identically. Linux+ does not ask you to master any single one of these tools; it asks you to understand what problem each category solves and how they fit together — the conceptual map of modern automated operations that a DevOps or cloud role assumes.
The way to study this domain is to write and schedule something small that actually runs, which is exactly what the lab below does: you write a real bash script with a variable and a loop, make it executable, run it, and then schedule it with cron. Doing it turns 'automation' from a buzzword into a file you created and a job that fires on its own. As you go further, put your scripts under Git and read about one configuration-management or container tool to sketch the bigger map. And read the official CompTIA Linux+ objectives page for the exact topic list; this explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Build the smallest complete unit of real automation with your own hands: write a bash script that uses a variable and a loop, make it executable and run it, then schedule it to run automatically with cron. You will turn 'automation' from a word into a file you wrote and a job that fires on its own.
An executable bash script that prints a greeting built from a variable and counts through a loop; an exit code of 0 confirming it succeeded; a log file that grows a new timestamped line every minute without you running anything; and a crontab you can list, edit, and clean up. You have written automation and watched a scheduler run it for you — the smallest complete piece of the DevOps skillset.
This lab practices the shell-scripting (variables, loops, exit codes) and task-scheduling skills that Domain 4 (Automation, Orchestration, and Scripting) of the official XK0-006 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: Do this only on a Linux environment you own. Scripts run with your permissions, so read every command before you run it and never paste a script from an untrusted source without understanding it. Schedule the per-minute demo job only long enough to see it work, then remove it so it does not run indefinitely. Every 'rm' here targets a specific path you created — never run 'rm -r' or 'rm -rf' against broad or system directories, and never schedule a destructive command.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Studying CompTIA Linux+builds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Check your CompTIA Linux+ readiness →Full CompTIA Linux+ decision page →
A free, source-cited study companion built on CompTIA's published XK0-006 objectives — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by CompTIA.