RoleMath

Free training - skill primer

Learn Troubleshooting for free

A free, source-cited path to learning structured technical troubleshooting by practicing it on a machine you own — this is a learning path, not a certification and not a job guarantee. A method is built by using it on real broken things, not by memorizing the steps.

What it is

Troubleshooting is the structured skill of isolating, diagnosing, and resolving problems in hardware, software, networks, and services — and doing it in a repeatable order rather than by guessing. Almost every IT and support role is really a troubleshooting role: something is not working, and someone has to find out why and fix it without breaking anything else. Because the method is the same whether you are chasing a failed login, a dead network link, or a service that will not start, this is one of the most transferable skills in technology. You can learn it entirely on a computer or virtual machine you own by deliberately breaking things and walking them back to health.

The canonical framing is a six-step loop, most widely taught through CompTIA's troubleshooting methodology. First, identify the problem: gather information, reproduce it, ask what changed, and question the obvious. Second, establish a theory of probable cause — the most likely explanation, questioning the obvious first. Third, test the theory: if it is confirmed, move on; if not, form a new one or escalate. Fourth, plan and implement the fix, considering side effects. Fifth, verify full system functionality and put preventive measures in place so it does not recur. Sixth, document what happened, what fixed it, and the outcome — so the next person (often future you) starts ahead. The discipline is in following the loop instead of skipping to a fix.

The habit that ties it all together is reading the evidence before acting: logs, status commands, and error messages usually tell you what failed if you slow down and look. The fastest way to build the reflex is a disposable environment where you can safely break a real service, observe the failure, walk the six steps, and revert. This primer sequences the free resources and gives you a first hands-on exercise where you break a service on purpose and fix it by the book.

Why it matters

Structured troubleshooting shows up in nearly every IT role — help desk, IT support, system administration, and network administration — because the core job is turning a broken thing back into a working one. The six-step method transfers across employers, platforms, and problem types, so the skill compounds rather than locking you to one tool or vendor.

The free path, in order

  1. Learn the six-step method cold. Read CompTIA's troubleshooting-methodology explainer and be able to name the steps in order: identify the problem, establish a theory, test the theory, plan and implement, verify and prevent, document. This loop is the whole skill.
  2. Stand up a free practice environment. Install VirtualBox and a free Linux VM (Ubuntu is fine), or use a spare PC you own. Take a snapshot so you can deliberately break things and revert. This sandbox is where every practice run happens.
  3. Build the habit of reading the evidence. Before touching a fix, practice gathering information: reproduce the problem, check status ('systemctl status <service>'), and read logs ('journalctl' on Linux, Event Viewer on Windows). The answer is usually already written down.
  4. Practice on deliberately broken systems. Break something on purpose on your VM (a bad config, a stopped service, a wrong permission), then walk all six steps out loud or on paper. The point is to follow the loop even when you think you already know the answer.
  5. Document every run. Keep a running troubleshooting log: symptom, what you checked, your theory, the test, the fix, and how you verified it. Documentation is step six of the method and the habit that separates guessing from diagnosing.

Best free resources

Every resource is free and dated. Official sources are labeled; vetted community resources are labeled separately. Verify a resource is still free on its own page before relying on it.

Try it (free, safe, hands-on)

Break it on purpose, then fix it by the six steps

Deliberately break a service on a VM you own, then diagnose and fix it using CompTIA's six-step method — documenting each step so the loop becomes a habit instead of a guess.

You will need: VirtualBox with a free Ubuntu VM you created, or a spare PC you own; A terminal on that VM — free, already present; A VM snapshot taken before you start, so you can revert; A plain text file or notebook to document each step

  1. Snapshot your VM. Install a simple service to break: 'sudo apt-get install -y nginx', confirm it works with 'systemctl status nginx' and by loading http://localhost in the VM's browser.
  2. Break it on purpose: edit the config with 'sudo nano /etc/nginx/nginx.conf' and introduce an obvious error (for example, delete a closing '}' or a semicolon). Save, then try 'sudo systemctl restart nginx' and watch it fail.
  3. Step 1-2, identify and theorize: write down the symptom (service will not restart), then form a theory. Ask 'what changed?' — you changed the config — and question the obvious first.
  4. Step 3, test the theory: read the evidence with 'sudo nginx -t' and 'sudo journalctl -u nginx --no-pager | tail'. The error message points to the exact line. Confirm your theory matches what the logs say.
  5. Step 4-5, fix and verify: correct the config, run 'sudo nginx -t' until it reports 'syntax is ok', restart the service, and verify with 'systemctl status nginx' and by reloading http://localhost. As a preventive measure, note that 'nginx -t' should be run before every restart.
  6. Step 6, document: in your notes, record the symptom, the check that revealed the cause, the fix, and how you verified it. Then revert to your snapshot or remove nginx to clean up.

What you should see: A service you broke on purpose and brought back to health by following the six steps in order, an error log that told you exactly what was wrong once you read it, and a short written record of the whole run — all on a machine you own.

Safety: Do this only on a virtual machine or personal computer you own. Never break, poke at, or 'test' an employer, school, or shared system without written authorization. Snapshot first so you can always revert; nothing here touches any system outside your own VM.

Where this skill gets used

Certifications that test it: comptia-a-plus, comptia-network-plus, comptia-server-plus, linux-foundation-certified-kubernetes-administrator-cka, comptia-linux-plus, comptia-cysa-plus, comptia-tech-plus.

Roles that need it: IT support specialist, Help desk technician, Systems administrator, Network administrator.

Sources

Every resource is free and dated; official-first, community clearly labeled. A skill primer is a free learning path, not a certification, not professional experience, and not a job or salary promise. Labs run only on a machine you own — never on systems you do not control. Born draft, pending human review.

All skill primers