Overview
Troubleshooting is 22% of the XK0-006 exam and has five objectives. Objective 5.1 covers monitoring: service levels (SLA, SLO, SLI), data collection through SNMP, agents, agentless polling, webhooks, health checks and log aggregation, and the thresholds, alerts and notifications built on them. Objectives 5.2 to 5.5 are symptom-driven: hardware, storage and OS faults such as kernel panics, GRUB errors, unmountable filesystems, inode exhaustion and memory leaks; networking faults such as DNS, DHCP, routing, MTU mismatches and link negotiation; security faults such as SELinux denials, ACLs, expired accounts, certificates and cipher mismatches; and performance problems such as swapping, high load, I/O wait, packet loss and latency.
The objectives list symptoms rather than tools, so the domain draws on the commands taught in Domains 1 to 4. It is where the exam checks whether that knowledge works under pressure.
How it's tested
Expect scenario questions that describe symptoms and often include command output: dmesg lines, systemctl status, ip route, top or vmstat figures, an AVC denial or a certificate date. You choose the most likely cause, the next diagnostic step or the best fix. Read every number in the output; one value usually decides the answer.
-
Most likely cause
Symptoms plus output point to one root cause among several plausible ones, such as a missing default route rather than a DNS fault.
-
Next step
You choose the diagnostic that best narrows the problem, such as checking df -i before extending storage or ip link before reconfiguring DNS.
-
Interpret the metric
Load averages, iowait, swap activity, SLO figures or packet loss are given, and you decide what resource or service level is actually at risk.
A four-core server shows a load average of 9, yet top reports the CPU around 80% idle with a high wa value and many processes in state D. High load with idle CPUs means tasks are queued waiting, and D is uninterruptible sleep, usually on disk I/O. The bottleneck is storage, so the next step is iostat to find the saturated device, not adding CPUs or renicing processes.
Objectives 5
Official objectives from the CompTIA outline, in outline order.
5.1 Summarize monitoring concepts and configurations in a Linux system.Service levels, SNMP, agent and agentless collection, health checks, log aggregation and alerting.
- What it means
- Covers service-level terms (SLA, SLO, SLI), data acquisition through SNMP traps and MIBs, agent-based versus agentless collection, webhooks, health checks and log aggregation, and configuring thresholds, alerts, events, notifications and logging.
- What to understand
- An SLI is the measured indicator, such as the percentage of successful requests; an SLO is the internal target for it; an SLA is the contractual commitment to a customer, usually looser than the SLO. SNMP agents answer polls from a manager and can push traps when something happens; MIBs define the objects that can be queried. Thresholds should reflect a baseline, or alerts become noise.
- How it shows up
- You classify a statement as an SLA, SLO or SLI, choose push (trap or webhook) versus poll collection, or fix an alerting setup that floods staff with alerts nobody acts on.
- Common confusion
- Swapping SLO and SLA. The SLO is the team's own target; the SLA is the external promise with consequences if missed.
5.2 Given a scenario, analyze and troubleshoot hardware, storage, and Linux OS issues.Kernel panics, boot and GRUB errors, mount failures, full disks, inodes, crashes, unit failures, quotas and leaks.
- What it means
- Covers kernel panic and corruption, data corruption, package dependency problems, filesystems that will not mount, servers that will not power on or are inaccessible, full OS filesystems, inode exhaustion, partitions that are not writable, segmentation faults, GRUB misconfiguration, killed or unresponsive processes, PATH misconfiguration, systemd unit failures, missing or disabled drivers, quota issues and memory leaks.
- What to understand
- A bad /etc/fstab entry can drop boot into emergency mode; compare UUIDs with blkid and test with mount -a. A filesystem that suddenly turns read-only has often been remounted after errors and needs fsck while unmounted. Processes that vanish under memory pressure were usually chosen by the out-of-memory (OOM) killer, which dmesg records. A panic straight after a kernel update is resolved by booting the previous kernel from the GRUB menu.
- How it shows up
- A server boots to emergency mode after a disk change, a filesystem is read-only, a service is listed by systemctl --failed, or memory use climbs steadily until a process is killed.
- Common confusion
- Treating "command not found" as a missing package when the binary is installed but its directory is missing from PATH.
5.3 Given a scenario, analyze and troubleshoot networking issues on a Linux system.Firewall, DHCP, DNS, interface, routing, IP conflict, dual-stack and link problems.
- What it means
- Covers misconfigured firewalls, DHCP and DNS problems, interface misconfiguration (MTU mismatch, bonding, MAC spoofing, subnet errors, cannot ping server), routing and gateway issues, unreachable servers, IP conflicts, dual-stack IPv4/IPv6 issues, link down and link negotiation problems.
- What to understand
- Work up the stack: link (ip link, ethtool), address and mask (ip addr), routes (ip route), name resolution (dig, resolvectl), then the port and firewall (ss, nc, firewall-cmd). Reaching hosts by IP but not by name points to DNS; reaching the local subnet but nothing beyond points to the gateway. An MTU mismatch lets small packets through while large transfers stall.
- How it shows up
- Output from ip route, ip addr or ethtool is shown, and you pick the cause, such as a missing default route, a wrong subnet mask, a half-duplex link or an AAAA record pointing to an unreachable IPv6 address.
- Common confusion
- Blaming DNS for every "cannot reach" message. Test by IP address first to separate name resolution from connectivity.
5.4 Given a scenario, analyze and troubleshoot security issues on a Linux system.SELinux, permissions, ACLs and attributes, account access, patches, exposed services, certificates and ciphers.
- What it means
- Covers SELinux policy, context and boolean issues, file and directory permission problems including ACLs and attributes, account access failures, unpatched vulnerable systems, exposed or misconfigured services, remote access problems, certificate issues, misconfigured package repositories, obsolete or insecure protocols and ciphers, and cipher negotiation failures.
- What to understand
- When access is denied despite correct mode bits, check in order: execute permission on every parent directory, ACL entries and mask, file attributes with lsattr, then the SELinux context with ls -Z and the audit log. Account failures can come from a lock, an expired account (chage -l), a nologin shell or PAM lockout. TLS failures split into expired certificates, name mismatches, untrusted chains and no shared protocol or cipher.
- How it shows up
- A user can read a file as root but not as themselves, a web page fails only after files are moved, an SSH user is refused despite a correct password, or legacy clients fail after weak TLS versions are disabled.
- Common confusion
- Reaching for chmod when the denial comes from SELinux or an immutable attribute, which mode bits cannot override.
5.5 Given a scenario, analyze and troubleshoot performance issues.Memory, CPU, load, I/O wait, startup time, network latency and throughput, blocked processes and baselines.
- What it means
- Covers swapping and out-of-memory conditions, slow application response and system unresponsiveness, high CPU use, load average and context switching, high failed login attempts, slow startup, high I/O wait and disk latency, packet drops, jitter, random disconnects and timeouts, high latency and low throughput, blocked processes, hardware errors, sluggish terminals, exceeding baselines, slow remote storage and CPU bottlenecks.
- What to understand
- Load average counts runnable and uninterruptible tasks, so compare it with the CPU core count and check whether CPU is busy or waiting. vmstat shows swap-in and swap-out (si/so), context switches (cs) and blocked processes (b); iostat shows per-device utilisation and latency. systemd-analyze blame identifies slow boot units. A baseline is what makes a number abnormal.
- How it shows up
- Metrics are given and you identify the constrained resource: memory (swapping, OOM), CPU (high user or system time), storage (high wa, D-state processes) or network (drops, jitter, retransmits).
- Common confusion
- Reading a high load average as a CPU shortage. With idle CPUs and high iowait, the queue is waiting on storage.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
SLA, SLO and SLI
An SLI is a measured indicator such as request success rate or latency, an SLO is the internal target for that indicator, and an SLA is the external agreement with consequences if service falls below it.
- Remember
- SLOs are usually set stricter than the SLA so the team reacts before the contract is breached.
- Tested as
- Objective 5.1 classification and alerting questions.
- Trap
- Calling an internal target an SLA.
-
Availability arithmetic
Each extra nine in an availability target sharply cuts permitted downtime: 99.9% over a 30-day month allows about 43 minutes, while 99.99% allows about 4.3 minutes.
- Remember
- Downtime budget equals (1 minus availability) multiplied by the period.
- Tested as
- Interpreting what a stated SLO allows.
- Trap
- Assuming 99.9% means only a few seconds of downtime.
-
SNMP polling and traps
A manager polls SNMP agents for values defined in MIBs, normally on UDP 161, while agents send unsolicited traps to the manager, normally on UDP 162, when an event occurs.
- Remember
- SNMPv3 adds authentication and encryption; v1 and v2c rely on community strings.
- Tested as
- Data acquisition questions in objective 5.1.
- Trap
- Expecting a polling interval to catch a brief event a trap would report immediately.
-
Alert thresholds and baselines
A threshold should be set against a measured baseline of normal behaviour and tied to an action, otherwise alerts fire constantly and staff start ignoring them.
- Remember
- Alert on symptoms that threaten SLOs; log or dashboard the rest.
- Tested as
- Alert-fatigue and missed-incident scenarios.
- Trap
- Lowering thresholds further when alerts are already being ignored.
-
Emergency mode after fstab changes
If a filesystem listed in /etc/fstab cannot be mounted at boot, systemd may drop to emergency mode, commonly because of a wrong UUID or a removed disk.
- Remember
- Check blkid against fstab, fix or comment the line, add nofail for optional devices, then run mount -a.
- Tested as
- Boot failure after storage changes.
- Trap
- Reinstalling GRUB when the bootloader works and only a mount fails.
-
OOM killer
When memory and swap are exhausted, the kernel's out-of-memory killer terminates a process chosen by a scoring heuristic and logs the event in the kernel ring buffer.
- Remember
- dmesg or journalctl -k shows "Out of memory: Killed process" with the victim's PID.
- Tested as
- Processes that disappear without application errors.
- Trap
- Debugging the application's own logs and missing the kernel message.
-
Read-only remount
ext4 commonly remounts a filesystem read-only when it detects errors, protecting data from further damage and making the partition unwritable.
- Remember
- Check dmesg for I/O or filesystem errors, then run fsck with the filesystem unmounted.
- Tested as
- "Partition not writable" scenarios.
- Trap
- Running fsck on a mounted filesystem.
-
Layered network diagnosis
Network faults are isolated bottom up: link state, IP address and mask, routing and gateway, name resolution, then the service port and firewall.
- Remember
- If an IP address works and the name does not, the fault is DNS.
- Tested as
- Nearly every 5.3 question.
- Trap
- Changing DNS servers when ip route shows no default gateway.
-
MTU mismatch
When a path or interface has a smaller maximum transmission unit than the sender assumes, small packets succeed while large packets are dropped, often because ICMP feedback is blocked.
- Remember
- Test with ping -M do -s size to find the largest packet that passes without fragmentation.
- Tested as
- SSH logs in but hangs on large output, or tunnels stall on transfers.
- Trap
- Diagnosing it as a firewall block because some traffic works.
-
Duplex and negotiation mismatch
If one side auto-negotiates and the other is forced, the link can fall back to half duplex or a lower speed, causing errors, retransmits and poor throughput.
- Remember
- ethtool shows speed, duplex and whether a link is detected.
- Tested as
- Link negotiation and low-throughput scenarios.
- Trap
- Tuning application buffers when the physical link is the problem.
-
Denied despite correct permissions
Access can be blocked by missing execute permission on a parent directory, a restrictive ACL mask, an immutable or append-only attribute, or an SELinux context mismatch, all of which override the file's own mode bits.
- Remember
- Check namei -l or each directory, getfacl, lsattr, then ls -Z and the AVC log.
- Tested as
- Most 5.4 permission scenarios.
- Trap
- Using chmod 777, which fixes none of these causes.
-
Certificate failure types
TLS errors usually come from an expired certificate, a hostname that does not match the certificate's subject alternative names, a missing intermediate certificate or an untrusted root.
- Remember
- openssl s_client -connect host:443 shows the chain; openssl x509 -noout -dates shows validity.
- Tested as
- Certificate issue scenarios in objective 5.4.
- Trap
- Replacing a valid certificate when only the intermediate chain is missing.
-
Load average versus CPU count
Load average is the mean number of tasks running or waiting, including uninterruptible I/O waits, over 1, 5 and 15 minutes.
- Remember
- Compare it with the core count, then check CPU idle and iowait to see what tasks are waiting for.
- Tested as
- Performance scenarios with uptime or top output.
- Trap
- Concluding the CPU is saturated from load alone.
-
vmstat columns
vmstat reports processes waiting (r) and blocked (b), swap-in and swap-out (si, so), I/O, context switches (cs) and CPU split into user, system, idle and wait.
- Remember
- Sustained non-zero si and so means active swapping and memory pressure.
- Tested as
- Metric-interpretation questions.
- Trap
- Treating a large but static swap-used figure as active swapping.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SLA vs. SLO vs. SLI
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SLI | Measured indicator of service behaviour | The actual number, such as 99.95% of requests succeeding | Calling the measurement a target |
| SLO | Internal target for an SLI | Set by the team, usually stricter than the SLA | Treating it as a contract with customers |
| SLA | Agreement with customers on service levels | Carries consequences such as service credits when missed | Using it as the alerting threshold |
CPU-bound vs. memory-bound vs. I/O-bound vs. network-bound
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| CPU-bound | Processor time is the constraint | High user or system CPU with little idle time | Adding RAM to a CPU-saturated host |
| Memory-bound | RAM is exhausted | Sustained swap-in and swap-out, OOM kills | Reading cached memory as used memory |
| I/O-bound | Storage cannot keep up | High iowait, D-state processes, high device latency in iostat | Mistaking high load for a CPU problem |
| Network-bound | The network path limits the service | Packet drops, retransmits, jitter or low throughput | Tuning the server when the link or path is the issue |
DNS fault vs. gateway fault vs. MTU fault vs. firewall fault
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| DNS fault | Names do not resolve correctly | Works by IP address, fails by name | Changing routes when only resolution fails |
| Gateway fault | No valid route off the local subnet | Local hosts reachable, remote ones not; no default route | Blaming DNS for remote failures |
| MTU fault | Large packets dropped on the path | Connections open, large transfers stall | Assuming a firewall block because some traffic works |
| Firewall fault | Rules block a port or source | Host reachable, one service port refused or filtered | Testing with ping, which may be allowed separately |
Mode bits vs. ACL vs. attribute vs. SELinux denial
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Mode bits | Owner, group and other read, write and execute | Includes execute on every parent directory | Checking only the file, not its path |
| ACL | Extra named user and group entries | The mask can cap effective rights | Missing the + in ls -l output |
| Attribute | chattr flags such as immutable or append-only | Blocks changes even by root | Not checking lsattr when root cannot edit a file |
| SELinux | Mandatory access control by context | Denials appear as AVC records in the audit log | Changing mode bits when the context is wrong |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Fix before diagnosis
- What candidates pick
- Restart the service or reboot the server as the first step.
- Why it looks right
- Restarts often make symptoms go away briefly.
- Why it's wrong
- It destroys evidence and leaves causes such as a full disk, a bad unit file or a memory leak in place; the exam favours confirming the cause first.
Clue to watch for The question asks for the FIRST or NEXT step, or the problem recurs.
-
Load means CPU
- What candidates pick
- Add vCPUs or renice processes when the load average is high.
- Why it looks right
- Load average is widely read as CPU busyness.
- Why it's wrong
- Load includes tasks waiting on I/O; with idle CPUs and high wa the constraint is storage.
Clue to watch for top or vmstat shows high wa, low user CPU, or processes in state D.
-
Everything is DNS
- What candidates pick
- Edit DNS settings when a server cannot reach external sites.
- Why it looks right
- Name resolution failures are common and familiar.
- Why it's wrong
- If external IP addresses are also unreachable, routing is broken; DNS changes will not help.
Clue to watch for ip route shows no default route, or pinging a public IP address also fails.
-
chmod for every denial
- What candidates pick
- chmod 777 on a file a service cannot read.
- Why it looks right
- It removes every mode-bit restriction at once.
- Why it's wrong
- It weakens security and does nothing if SELinux, an ACL mask, an attribute or a parent directory is the block.
Clue to watch for The mode bits already allow access, or files were recently moved or restored.
-
Reinstall instead of roll back
- What candidates pick
- Rebuild the server after a kernel panic that began with a kernel update.
- Why it looks right
- A panic looks like a deep OS failure.
- Why it's wrong
- GRUB keeps previous kernels; booting the last working one restores service while you rebuild the initramfs or fix the driver.
Clue to watch for The panic started immediately after a kernel or driver update.
-
More alerts for missed incidents
- What candidates pick
- Add lower thresholds and more notifications after an outage went unnoticed.
- Why it looks right
- More alerts seem to mean more coverage.
- Why it's wrong
- If staff already ignore noisy alerts, more noise makes it worse; thresholds should follow baselines and SLOs and route actionable alerts only.
Clue to watch for Alerts were firing but nobody responded.
-
Cipher failure blamed on the certificate
- What candidates pick
- Replace the server certificate when old clients fail after a TLS hardening change.
- Why it looks right
- TLS errors are often certificate errors.
- Why it's wrong
- If only legacy clients fail right after TLS 1.0 and 1.1 were disabled, there is no shared protocol or cipher; the client needs updating.
Clue to watch for Modern clients connect fine and the failures began with a protocol or cipher change.
Answer framework
For any Linux troubleshooting scenario, confirm the cause from the evidence before changing anything.
- Restate the symptom precisely: what fails, for whom, since when, and what changed just before it started.
- Read every piece of given output, such as dmesg, systemctl status, ip route, top or an AVC record, and note the one value that is abnormal.
- Isolate the layer by testing from the bottom up: hardware and link, storage and filesystem, network path, service and permissions, then application.
- Choose the diagnostic or fix that addresses that cause directly and narrowly, such as booting the previous kernel or adding a route.
- Prefer reversible actions, verify the result against the original symptom, and update monitoring so the issue is detected earlier next time.
Practice question
Want more like this? The CompTIA Linux+ practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study this domain last, after Domains 1 to 4, because it uses their tools. Start with networking (5.3) and the bottom-up method: on a lab VM, remove the default route, break DNS, set a wrong subnet mask and lower the MTU, and practise identifying each from ip, dig and ping output alone.
Next, do hardware, storage and OS faults (5.2) hands-on: add a bad UUID to /etc/fstab and recover from emergency mode, fill a filesystem with small files, boot an older kernel from the GRUB menu, and trigger a failing systemd unit. Then cover security troubleshooting (5.4) by moving web content to break SELinux labels, setting an ACL mask and an immutable attribute, and expiring a test account.
The most underestimated areas are performance (5.5) and monitoring (5.1). Learn to read load average alongside iowait, vmstat's si, so, b and cs columns, and iostat device latency. Memorise the SLA, SLO and SLI distinctions and SNMP basics, since they are quick points.
Afterwards, practise with output-heavy scenario questions under time pressure, and for each miss, write down the one value in the output you should have noticed.
FAQ
How much of Linux+ XK0-006 is Troubleshooting?
Troubleshooting is 22% of the exam, second only to System Management, with five official objectives. Against the 90-question maximum that is about 20 items, an editorial planning estimate.
Why is monitoring part of the Troubleshooting domain?
Objective 5.1 covers how problems are detected: service levels, SNMP, health checks, log aggregation and alerting. Good monitoring tells you something is wrong and provides the baseline that makes troubleshooting data meaningful.
The objectives list symptoms, not tools. Which tools should I know?
The tools come from the other domains: dmesg, journalctl, systemctl, df, lsblk, blkid and fsck for OS and storage; ip, ss, dig and ethtool for networking; ls -Z, getfacl, lsattr and openssl for security; top, vmstat, iostat and free for performance.
How do I tell a CPU problem from an I/O problem?
Compare load average with the number of cores, then look at CPU breakdown. High user or system time with little idle points to CPU, while idle CPUs with high iowait and processes in state D point to storage.
What is the fastest way to separate DNS problems from connectivity problems?
Test the same destination by IP address and by name. If the IP works and the name fails, focus on DNS; if both fail, check the link, address and default route first.
Are troubleshooting questions performance-based?
CompTIA states the exam contains performance-based questions but does not publish which objectives they cover. Symptom-driven objectives suit that format, so practise working from real command output.
Should I study Troubleshooting first or last?
Last, or alongside the domains it draws from. Each objective here is a failure view of earlier content, so it consolidates System Management, services, security and automation knowledge.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered monitoring and service levels, boot and storage faults, network isolation, security-related failures and performance metrics. Test whether you can find the one abnormal value in real output under time pressure.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the CompTIA Linux+ AI tutor Get any concept explained your way