23 Troubleshooting: Network & Performance Practice Questions & Answers

1. 1. A user reports that an internal application is unreachable from a Linux server. On that server, `ping 10.40.12.15` (the application server's address) succeeds with normal round-trip times, while `ping app.corp.example` returns 'ping: app.corp.example: Name or service not known'. What has this evidence established, and what should be examined next?

   • A.Routing-layer reachability is proven, so the fault lies in name resolution — check the nameserver entries in /etc/resolv.conf and the output of resolvectl status.✓ Answer
   • B.The default gateway is missing, so no remote network can be reached — compare the entries printed by ip route with the address configured on that interface.
   • C.The application's port is being filtered, so sessions never open at all — review the active zone and its allowed ports with firewall-cmd --list-all there.
   • D.The interface holds no usable lease, so nothing at all leaves the host — check the device state and the active connection profile with nmcli device status.

   A successful ping to the literal address exercises the interface, the route and the remote host, so everything up to the routing layer is working; the same ping by name failing with a resolver error rather than a timeout isolates the problem to the name-resolution step, which on a systemd-resolved host is configured through /etc/resolv.conf and reported by resolvectl status.

   Source: CompTIA Linux+ exam objectives, Troubleshooting domain — analyzing networking issues (DNS issues); resolv.conf(5) and systemd-resolved(8) manual pagesReport a problem with this question

2. 2. On a Linux host, `dig +short files.corp.example` returns '10.60.4.20', but `getent hosts files.corp.example` prints nothing and the application fails with 'Temporary failure in name resolution'. Which file should be examined first, and why?

   • A./etc/resolv.conf, because dig reads its own separate configuration while the C library takes its nameserver list from that file alone.
   • B./etc/nsswitch.conf, because its hosts line decides which sources the C library consults, while dig queries DNS servers directly.✓ Answer
   • C./etc/hosts, because a static entry there is returned to dig before any nameserver is contacted, which is why the two tools disagree.
   • D./etc/services, because the library resolves the service name to a port number before it attempts any address lookup for the host.

   dig sends its query straight to a DNS server, so a successful dig proves DNS itself is answering; getent exercises the full Name Service Switch path used by ordinary programs, so when one works and the other does not, the discrepancy lies in the switch configuration — the hosts line of /etc/nsswitch.conf, which lists and orders the sources the C library is allowed to use.

   Source: nsswitch.conf(5) and getent(1) manual pages; CompTIA Linux+ exam objectives, network services and configuration (/etc/nsswitch.conf)Report a problem with this question

3. 3. A web service was migrated to a new address. On a Linux client, `dig +short reports.corp.example` returns '172.18.9.60', but `getent hosts reports.corp.example` prints '172.18.9.31 reports.corp.example' and curl still connects to 172.18.9.31. What is the most likely cause?

   • A.The record's time-to-live has not expired on the authoritative server, so every query still receives the previous address until it does.
   • B.curl keeps its own address cache between invocations, so it reuses the address from the last connection it managed to complete successfully.
   • C.A stale entry for that name in /etc/hosts is consulted ahead of DNS, so the library returns the old address while dig returns the new one.✓ Answer
   • D.A second search suffix in /etc/resolv.conf is appended first, so the name is answered out of a different zone than the one dig queried.

   On a host whose Name Service Switch lists files before dns, an entry in /etc/hosts wins outright and no DNS query is made for that name, while dig never reads /etc/hosts and therefore reports the current DNS answer. A divergence between dig and getent or curl is the signature of a local static entry, and unlike a cached DNS answer it never expires on its own.

   Source: hosts(5) and nsswitch.conf(5) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — DNS issuesReport a problem with this question

4. 4. Two Linux servers sit on the same subnet. From serverA, `getent hosts vpn.corp.example` returns an address; from serverB the same command returns nothing, although `ping` to that address from serverB succeeds and both hosts reach the internet. What is the most probable cause, and where should the check begin?

   • A.The authoritative zone is answering intermittently, so query its nameserver repeatedly from both hosts with dig until the answers start to differ.
   • B.serverB advertises a smaller MTU, so the larger response is discarded in transit — size the path from serverB with ping -M do -s before anything else.
   • C.The two hosts are querying different resolvers, so compare the nameserver and search settings each one is actually using with resolvectl status.✓ Answer
   • D.serverB's clock has drifted far enough that answer validation fails, so compare the time and synchronisation state on both hosts with timedatectl.

   Name resolution is per-host configuration: every machine has its own resolver list, search domains and Name Service Switch order, so an identical query can succeed on one host and fail on its neighbour even on a single subnet. Because ping to the address works from the failing host, connectivity and routing are intact, which points at that host's own resolver settings rather than at the network or the zone.

   Source: resolv.conf(5) and resolvectl(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — DNS issuesReport a problem with this question

5. 5. A Linux client runs `curl http://10.44.2.18:8080/health` and the command returns almost instantly with 'curl: (7) Failed to connect to 10.44.2.18 port 8080: Connection refused'. Ping to 10.44.2.18 succeeds. What does this error prove?

   • A.The service rejected the session during the handshake, so the transport opened and closed — test the negotiation from the client with openssl s_client.
   • B.A packet filter discarded the request on the way in, which is why the client stopped waiting — inspect the active rules with firewall-cmd --list-all.
   • C.The route towards that network is missing, so the request never left the client — display the route the kernel would choose with ip route get 10.44.2.18.
   • D.The packet reached the host and the kernel replied with a reset because no process is listening on that port — confirm the listening sockets with ss -tulnp.✓ Answer

   A refusal is an answer: the destination received the segment and its kernel returned a reset, which happens when nothing is bound to that port, so the interface, the route and the host are all proven good and the investigation moves to the service and its listening socket. Because the reply is immediate rather than delayed, silent filtering and a missing route are both excluded, and ss -tulnp shows which address and port the service actually claimed.

   Source: ss(8) manual page and curl exit-code documentation; CompTIA Linux+ exam objectives, Troubleshooting domain — server unreachable versus a service that is not listeningReport a problem with this question

6. 6. On the same Linux host, `nc -vz 10.44.2.18 8080` waits a long time and ends with 'Connection timed out', while `nc -vz 10.44.2.18 9100` returns at once with 'Connection refused'. Which explanation fits both results?

   • A.Neither port has a listener, and the delay on 8080 only reflects a slower application accepting the handshake than the one behind 9100.
   • B.The process behind 8080 is stuck in uninterruptible sleep and cannot accept, while the process behind 9100 is running and rejecting requests.
   • C.Traffic to 8080 is being dropped silently before any process sees it, while 9100 produced a reset from a host that has nothing bound to it.✓ Answer
   • D.Port 8080 is blocked inside the application's own access control, while 9100 is filtered by the packet filter that sits in front of the host.

   The two failures come from different mechanisms: a filter that drops a packet gives the client no answer at all, so the client retransmits until its own timeout expires, whereas a port with no listener produces an immediate reset that is reported as 'Connection refused'. A timeout therefore points at silent filtering or a black-hole path, and a refusal points at a reachable host whose service is missing or stopped.

   Source: CompTIA Linux+ exam objectives, Troubleshooting domain — misconfigured firewalls and server unreachable; firewalld and nftables documentation on drop versus reject targetsReport a problem with this question

7. 7. A reporting daemon on a Linux server answers `curl http://localhost:9000` on the server itself, but every remote client times out even though the firewall permits 9000/tcp. `ss -tulnp` shows: 'LISTEN 0 128 127.0.0.1:9000 0.0.0.0:* users:(("reportd",pid=1422,fd=6))'. What is the cause?

   • A.The firewall rule went into a zone the interface does not use, so remote packets are discarded by the filter before they reach the daemon.
   • B.The listen backlog of 128 is exhausted by local clients, so remote handshakes sit in the queue until the client gives up and reports a timeout.
   • C.The daemon is bound to the loopback address alone, so packets arriving on the physical interface have no matching socket to be delivered to.✓ Answer
   • D.The daemon runs without privileges, so the kernel accepts its local clients but refuses connections that arrive from outside the host itself.

   A socket bound to 127.0.0.1 exists only in the loopback path, so a packet arriving on a physical interface for port 9000 finds no matching socket and is answered with a reset or dropped, no matter what the firewall allows. The fix belongs to the service's own configuration — bind it to a routable address or to the wildcard and restart it — and ss is what reveals which address a service actually claimed.

   Source: ss(8) and ip(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — services bound to the wrong addressReport a problem with this question

8. 8. A Linux host shows 'inet 10.10.4.37/16 brd 10.10.255.255 scope global ens192' and a routing table containing 'default via 10.10.4.1 dev ens192' plus '10.10.0.0/16 dev ens192 proto kernel scope link'. The segment it is attached to is actually 10.10.4.0/24, and the rest of 10.10.0.0/16 is routed behind the gateway. Neighbours on 10.10.4.0/24 and internet hosts respond, but `ssh 10.10.9.20` fails at once with 'connect: No route to host'. Why?

   • A.The broadcast address derived from that prefix is wrong, so address resolution cannot complete for any destination outside the host's own /24 block.
   • B.The default route is unusable because its next hop falls inside a link-scope network, so the kernel discards off-segment traffic before transmitting it.
   • C.The prefix is too wide, so the host believes 10.10.9.20 is directly attached and tries to resolve it with ARP on the segment instead of using the gateway.✓ Answer
   • D.The gateway has no return route for a /16 source address, so replies from 10.10.9.20 are dropped on the way back and the client reports the failure.

   The prefix length is what tells the kernel which addresses are on-link. With /16 configured, the kernel installs a link-scope route covering all of 10.10.0.0/16, and that more specific route beats the default route, so packets for 10.10.9.20 are never handed to the gateway; the host instead tries to ARP for a station that is not on the wire and fails immediately with 'No route to host'. Correcting the prefix to /24 restores the gateway path for the rest of the /16.

   Source: ip-address(8) and ip-route(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — interface misconfiguration (subnet) and routing issuesReport a problem with this question

9. 9. A newly provisioned Linux server managed by NetworkManager reaches every host on its own subnet but nothing beyond it, and queries to an off-subnet resolver time out. `ip route` prints one line only: '10.50.8.0/24 dev eth0 proto kernel scope link src 10.50.8.22'. Which conclusion follows, and what is the correct next step?

   • A.Reverse path filtering is discarding the answers as they return — relax the rp_filter setting for that interface with sysctl and retest the connection.
   • B.The link is administratively down, so only neighbours already held in the cache still answer — bring the interface up and confirm the carrier state with ip link.
   • C.The resolver list is empty, so the name queries never reach a server at all — add the nameserver addresses to the NetworkManager profile with nmcli.
   • D.No default route is installed, so traffic for other networks has nowhere to go — set the gateway in the NetworkManager profile with nmcli and reactivate it.✓ Answer

   The kernel forwards a packet only when a route matches its destination, so with a single link-scope route for the local /24 and no default route, everything outside 10.50.8.0/24 fails at once and an off-subnet resolver becomes unreachable, which is why name lookups time out too. On a NetworkManager host the durable fix is to put the gateway into the connection profile so it survives reactivation and reboot, rather than adding a route by hand.

   Source: ip-route(8) and nmcli(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — routing issues (gateway)Report a problem with this question

10. 10. Across a tunnel between two sites, `ping -c 4` to a Linux server reports no loss, SSH connects and prints its banner and then freezes, and large HTTPS downloads stall after a few kilobytes. From the client, `ping -M do -s 1472 remote` returns 'From 10.1.1.1 icmp_seq=1 Frag needed and DF set (mtu=1400)', while `ping -M do -s 1372 remote` succeeds. What is happening?

    • A.The remote firewall rate-limits the session as soon as bulk transfer begins, so the handshake completes normally and throughput then collapses to nothing.
    • B.The two ends of the local link disagree about duplex, so errors appear only when the link carries sustained traffic in both directions at once.
    • C.The tunnel's cipher renegotiation fails partway through, so the banner is exchanged but no data can cross once the keys are renewed mid-session.
    • D.A hop in the path accepts a smaller packet than the interface advertises, so full-size segments are discarded and the session stalls after its small exchanges.✓ Answer

    Small packets and the initial handshake fit inside the smallest link in the path, so reachability tests and login banners succeed; as soon as the session sends full-size segments they exceed that limit and are discarded, which is exactly what the 'Frag needed and DF set (mtu=1400)' reply reports, and the largest payload that passes with ping -M do measures the usable path size. The remedy is to set the interface or tunnel packet size to match that path.

    Source: ping(8) manual page and kernel networking documentation on path MTU discovery; CompTIA Linux+ exam objectives, Troubleshooting domain — interface misconfiguration (MTU mismatch)Report a problem with this question

11. 11. A statically addressed Linux database server drops off the network for seconds at a time. A tcpdump on a neighbouring host shows 'ARP, Reply 10.50.8.40 is-at 00:50:56:9a:11:22' and, moments later, 'ARP, Reply 10.50.8.40 is-at 52:54:00:3c:4d:5e', and the server's journal records an address collision. Which first action identifies the offending device?

    • A.Restart the network service on the database server so it claims the address again and the duplicate entry is flushed from the segment.
    • B.Take the hardware address that does not belong to the server and trace it to a switch port through the switch's forwarding table.✓ Answer
    • C.Shorten the neighbour cache lifetime on the database server with sysctl so that outdated hardware addresses are discarded far sooner.
    • D.Move the database server to an address handed out by DHCP so that it receives an address no other device on the segment is using.

    Two different hardware addresses answering ARP for one address is the signature of an address conflict, and the collision message in the journal confirms the server itself detected a competing claimant. The only piece of information that leads to the second machine is the unexpected hardware address, which the switch forwarding tables map to a port and therefore to a device; renewing or changing the server's own address hides the symptom without removing the duplicate.

    Source: ip-neighbour(8) and arp(8) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — IP conflictsReport a problem with this question

12. 12. On an RPM-based server running firewalld, an administrator ran 'firewall-cmd --zone=public --add-port=8443/tcp' and clients then connected successfully. After the next reboot the connections time out again and 'firewall-cmd --list-ports' prints nothing. What explains this?

    • A.The interface was assigned to its default zone at boot, so the port is now allowed in a zone that no interface on the server is bound to.
    • B.The port was allowed without a matching service definition, and firewalld removes port rules that no service claims when it next starts up.
    • C.The change never took effect at all, because a runtime port only begins to match new connections once firewall-cmd --reload has been issued afterwards.
    • D.The port went into the runtime configuration, which firewalld discards on reload or restart unless the same change is also written with --permanent.✓ Answer

    firewalld keeps two configurations: the runtime one, which takes effect immediately and is lost on reload, restart or reboot, and the permanent one, which is loaded at startup. A change made without --permanent therefore works until the service reloads and then disappears, which is why the durable sequence is to add the port with --permanent and then reload so the saved configuration becomes the running one.

    Source: firewall-cmd(1) and firewalld.zone(5) documentation on runtime versus permanent configuration; CompTIA Linux+ exam objectives, firewall configurationReport a problem with this question

13. 13. Users report that applications on an eight-core Linux server are slow. 'uptime' shows 'load average: 16.42, 15.98, 14.21' and the top summary line reads '%Cpu(s): 3.1 us, 2.4 sy, 0.0 ni, 12.0 id, 82.1 wa, 0.0 hi, 0.4 si, 0.0 st'. What do these figures indicate?

    • A.Work is queued waiting on input and output rather than on processor time, so the storage path is the bottleneck despite a load average twice the core count.✓ Answer
    • B.The processors are saturated because the load average sits well above the core count, so work has to be moved off this host or more cores provided.
    • C.Memory is exhausted and the kernel reclaims pages constantly, and that reclaim is the activity the waiting share of processor time represents here.
    • D.The figures are ordinary for a host of this size, because the load average counts every thread the scheduler tracks whether it is running or not.

    Load average counts processes wanting to run plus those blocked in uninterruptible sleep, so it measures demand rather than processor utilisation and only means something next to the core count and the breakdown of processor time. Here user and system time are tiny while 82.1 percent is wait, so the processors are mostly idle waiting for storage to complete requests and the investigation belongs to the disk or remote storage path.

    Source: proc(5) description of /proc/loadavg and top(1) manual page; CompTIA Linux+ exam objectives, Troubleshooting domain — high load average and high I/O wait timeReport a problem with this question

14. 14. An administrator is told a Linux server is out of memory. 'free -h' reports 'Mem: total 31Gi, used 9.8Gi, free 0.6Gi, shared 0.4Gi, buff/cache 21Gi, available 20Gi' and 'Swap: total 4.0Gi, used 0Ki, free 4.0Gi'. What does this output actually show?

    • A.The host is nearly out of memory, because the free column is the only memory the kernel can hand at once to a process that asks for more.
    • B.A leak is under way, since a cache that grows while free memory shrinks is how a leaking process gradually consumes the remainder.
    • C.Most of the memory is reclaimable page cache, and the available column is what new work can still obtain, so memory is not exhausted here.✓ Answer
    • D.Swap has already absorbed the pressure, so the unused swap figure shows the shortage was relieved and that no further action is needed now.

    Linux deliberately uses otherwise idle memory as page cache, so a small free figure is normal on a busy server because that cache is reclaimable on demand. The number describing real headroom is 'available', which estimates how much a new workload can allocate without pushing the system into swap, and here most of the total is available with swap untouched, so there is no shortage to act on.

    Source: free(1) manual page and proc(5) description of MemAvailable in /proc/meminfo; CompTIA Linux+ exam objectives, Troubleshooting domain — out of memory and memory leaksReport a problem with this question

15. 15. A Linux host feels sluggish even at the shell. A steady line of 'vmstat 1' reads: 'r 6 b 3 swpd 3891200 free 71232 buff 1024 cache 96256 si 2144 so 2560 bi 8412 bo 9100 in 6210 cs 14820 us 12 sy 9 id 4 wa 75 st 0'. Which reading of this output is correct?

    • A.The host is paging anonymous memory in and out continuously, and that disk traffic is what produces the wait time and the sluggish terminal.✓ Answer
    • B.The processor is the constraint, because a run queue above the core count together with steady context switching means the scheduler is saturated.
    • C.The columns show ordinary file activity, because the swap columns report only how much swap space the system currently has configured.
    • D.Swap should be removed to stop the disk traffic, because a host that is paging recovers as soon as its swap device is taken out of service.

    The si and so columns count memory moved between RAM and the swap device each second, so sustained non-zero values mean the system is actively paging, which is a consequence of a memory shortage rather than its cause. The blocked processes and the large wait share follow from that swap traffic competing with normal disk activity, so the fix is to reduce memory demand or add memory, not to take swap away.

    Source: vmstat(8) manual page and proc(5) memory fields; CompTIA Linux+ exam objectives, Troubleshooting domain — swapping and system unresponsivenessReport a problem with this question

16. 16. A Java service disappears overnight with nothing in its own log. 'journalctl -k' for that period contains: 'Out of memory: Killed process 8123 (java) total-vm:9814232kB, anon-rss:7521288kB, file-rss:0kB, shmem-rss:0kB, UID:994 pgtables:15100kB oom_score_adj:0'. What does this establish, and what is the appropriate follow-up?

    • A.The kernel ran out of usable memory and killed the largest consumer, so size the service's memory use against the host and adjust its limits or add memory.✓ Answer
    • B.An administrator or a scheduled job terminated the service with a signal, so audit the job definitions and shell history for a stray kill in that window.
    • C.The allocation failed because no swap device exists, so adding swap will keep the kernel from selecting this process the next time memory runs short.
    • D.The service exited on its own and the kernel only recorded the event, so enable core dumps and analyse the next failure from the application side.

    The 'Out of memory: Killed process' line is written by the kernel's out-of-memory killer, which picks a victim by its badness score when an allocation cannot be satisfied, so its presence proves the host ended the process rather than the application failing, and the anon-rss figure shows how much resident anonymous memory the victim held. The follow-up is therefore capacity or a per-service memory limit, since swap only postpones the shortage.

    Source: kernel documentation on the out-of-memory killer and proc(5) oom_score_adj; CompTIA Linux+ exam objectives, Troubleshooting domain — out of memory and killed processesReport a problem with this question

17. 17. A nightly batch job on a Linux host takes far longer than usual while 'top' shows the host mostly idle. 'mpstat -P ALL 1' reports 'all: %usr 12.60 %sys 0.75 %iowait 0.10 %steal 0.00 %idle 86.50', 'CPU 0: %usr 99.00 %sys 1.00 %idle 0.00', and every other core above 95 percent idle. What does this indicate?

    • A.The scheduler is failing to balance the work, so the job should be pinned to a less busy core with taskset to spread the demand out.
    • B.A single-threaded process has saturated one core, so the aggregate idle figure conceals a genuine processor bottleneck for that job.✓ Answer
    • C.The host is idle and the delay comes from somewhere else, because the aggregate figure is what decides whether the processor constrains work.
    • D.An interrupt storm is consuming one core, so the remedy is to spread that device's interrupts across the other cores by changing IRQ affinity.

    Aggregate processor figures are averages across all cores, so one fully busy core on an otherwise quiet host appears only as a modest overall percentage and the per-core view is what exposes the saturation. Because the busy core's time is user time with negligible interrupt or wait time, the limit is the single thread doing the work, which is why the next step is to identify that process and parallelise or reschedule it rather than move it.

    Source: mpstat(1) and top(1) manual pages; CompTIA Linux+ exam objectives, Troubleshooting domain — CPU bottleneck and high CPU usageReport a problem with this question

18. 18. Database queries on a Linux server are slow while the processors are mostly idle. 'iostat -xz 1' reports for the data device: 'sdb r/s 412.0 w/s 128.0 rkB/s 6592.0 wkB/s 2048.0 aqu-sz 23.40 r_await 52.80 w_await 61.30 %util 99.80'. What does this evidence show?

    • A.The transfer rates are modest, so the device is not the constraint and the delay must come from the query plans running on the database instead.
    • B.The filesystem on the device is nearly full, which is why utilisation is reported close to one hundred percent for every request it is given.
    • C.The requests are too small to be efficient, so raising the read-ahead value until average request size grows is what will bring utilisation down.
    • D.The device is working at its limit with a long request queue and tens of milliseconds of service time, so storage latency is what the queries are waiting on.✓ Answer

    Per-device utilisation close to one hundred percent, together with an average queue depth far above one and await values in the tens of milliseconds, describes a saturated device whose requests spend most of their life queued rather than being served. Since processor time is idle while wait time accumulates, the bottleneck is the storage path, and %util describes how busy the device is, not how full the filesystem on it happens to be.

    Source: iostat(1) manual page; CompTIA Linux+ exam objectives, Troubleshooting domain — high disk latency, low throughput and high I/O wait timeReport a problem with this question

19. 19. On a Linux host, 'ps -eo pid,stat,wchan:20,comm' prints ' 4411 D wait_on_page_bit backupd' and ' 4520 Z - reportgen'. Both were already sent SIGKILL and both are still listed. How should each one be handled?

    • A.Send SIGKILL to both a second time, because an uninterruptible process and a zombie are both removed as soon as the same signal is delivered again.
    • B.Repair the stalled input and output path for the first, and have the parent reap the second, since neither state responds to signals.✓ Answer
    • C.Raise the priority of both with renice, so the scheduler can run them to completion and release the resources that they are still holding open.
    • D.Reboot the host, because a process left in either of these states has leaked kernel memory that cannot be reclaimed while the system keeps running.

    A process in D state is blocked inside the kernel on an operation that cannot be interrupted, so no signal is delivered to it until that input or output completes or fails, which makes the device, filesystem or network path it waits on the thing to fix. A zombie has already exited and holds nothing but its entry in the process table, which disappears when its parent calls wait, so signalling or restarting the parent clears it while signalling the zombie achieves nothing.

    Source: ps(1) process state codes and proc(5); CompTIA Linux+ exam objectives, process states including blocked and zombie, and signal handlingReport a problem with this question

20. 20. A web application on a Linux server begins refusing new connections under load and its log fills with 'accept: Too many open files'. The host has idle processors and several gigabytes of available memory. What is the cause, and how is it confirmed?

    • A.The process has reached its open-file limit — count the descriptors it holds with lsof and compare them with /proc/<PID>/limits.✓ Answer
    • B.The outbound port range is exhausted — no new socket can be allocated, which is checked in the ip_local_port_range kernel setting with sysctl.
    • C.The listen queue is too short for the arrival rate — connections are dropped at the socket layer, which the somaxconn setting shows with sysctl.
    • D.The filesystem has run out of inodes — free space remains but no new file can be created, which df -i confirms for the mounted filesystems.

    'Too many open files' is the error a process receives when it hits its own maximum number of open file descriptors, and every accepted socket consumes a descriptor exactly as an open file does, so a busy server can exhaust that ceiling while the machine itself has spare processor and memory. Counting the descriptors the process holds and reading the limits recorded for that process identifies it, and the ceiling is then raised for the service rather than for an interactive shell.

    Source: RLIMIT_NOFILE as described in proc(5) and the POSIX shell ulimit specification; CompTIA Linux+ exam objectives, process limitsReport a problem with this question

21. 21. A user reports only that 'the server is slow'. The Linux host runs several applications and no monitoring alert has fired. Which approach follows the accepted troubleshooting order?

    • A.Establish which resource is constrained, attribute that constraint to a specific process, then change one thing and verify the effect.✓ Answer
    • B.Restart the largest application first, since one restart clears leaked memory and stale connections faster than any measurement can find them.
    • C.Adjust the scheduling priorities of the busiest processes first, then see whether the complaint goes away once the adjustment has settled.
    • D.Capture the traffic on the interface first, because slowness that users notice is far more often a network problem than a host problem.

    Troubleshooting narrows a symptom step by step: a complaint as vague as 'slow' first has to be tied to a resource — processor, memory, storage or network — using the system's own counters, and only then to the process consuming it. Acting before measuring, by restarting or renicing, destroys the evidence and can mask the cause, and changing one variable at a time is what allows the verification step to attribute any improvement.

    Source: CompTIA Linux+ exam objectives, Troubleshooting domain — analyzing performance issues, and the methodology of identifying the problem, testing one change and verifying the resultReport a problem with this question

22. 22. Users report that a Linux server was unresponsive for about ten minutes overnight. By morning it behaves normally and the live tools show nothing unusual. Which approach recovers usable evidence about the event?

    • A.Run top and the per-process counters now, because the peak values they display accumulate since boot and therefore still describe the overnight event.
    • B.Read back the kernel and unit messages for that exact window with journalctl --since and --until, having first confirmed that the journal is stored persistently.✓ Answer
    • C.Reproduce the stall by loading the host during the day, since watching the resources live is the only way to attribute a problem that has already ended.
    • D.Inspect the shell history and the process table, because whatever caused the stall will still be present with the same process identifier this morning.

    Evidence for an event that has ended can only come from something that recorded it while it was happening. The journal keeps timestamped kernel and unit messages and can be queried for an arbitrary window with --since and --until, but only when it is configured to persist across reboots rather than living in memory, which is why confirming persistence is part of the answer; live tools describe the present and cannot be rewound.

    Source: journalctl(1) and journald.conf(5) documentation on time filtering and persistent storage; CompTIA Linux+ exam objectives, Troubleshooting domain — monitoring, logging and log correlationReport a problem with this question

23. 23. An administrator is asked whether 85 percent processor utilisation and a load average of 6 on an eight-core batch host represent a problem. Which consideration settles the question?

    • A.Any host above 80 percent utilisation is oversubscribed, so these figures are a problem no matter what the host is expected to be doing at the time.
    • B.A baseline recorded while the host was healthy shows whether these figures are normal for this workload, which is what makes a reading abnormal.✓ Answer
    • C.A load average below the core count is always safe, so the figures can be set aside without regard to what this host normally reports.
    • D.Processor figures mean nothing until memory and storage are quiet, so nothing can be concluded while any other resource is also in use.

    A single reading is not evidence on its own: the same utilisation can be healthy on a batch host designed to run its processors hard and alarming on a latency-sensitive service, and the load average has to be read against the core count as well. A baseline captured while the system was known good supplies the comparison that turns a number into a signal, and thresholds and alerts are meaningful only when they are derived from it.

    Source: CompTIA Linux+ exam objectives, Troubleshooting domain — monitoring concepts including baselines, thresholds and alerts (exceeding baselines)Report a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →