Skip to content
THE EXAMTOPICS EDITORIAL Explore practice exams

COMPTIA

A+ Core 1: Troubleshoot With Evidence

A laptop shuts down twice during a video meeting. The user blames the wireless network because both events occurred while online. A technician immediately replaces the network adapter, but the…

A laptop shuts down twice during a video meeting. The user blames the wireless network because both events occurred while online. A technician immediately replaces the network adapter, but the machine shuts down again during a local benchmark with networking disabled. The original observation was real; the explanation was wrong. Troubleshooting is the discipline of separating a symptom from its cause while minimizing unnecessary risk and disruption.

Hardware and Network Troubleshooting is the largest scored CompTIA A+ 220-1201 domain at 28%. Its scenarios span motherboards, processors, memory, storage, power, printers, networks and mobile devices. CompTIA’s published objectives also discuss a general troubleshooting method as supporting knowledge, but that method should not be presented as a sixth weighted exam domain. The key ability is choosing a safe, justified next action based on the evidence available.

Define the problem before trying to fix it

Users describe impact, not component failure. “The internet is broken” may mean one website times out while other services work. “The printer is dead” may mean the printer can print a status page but jobs never leave a local queue. “The laptop has no power” may mean a drained battery, unsupported charger, damaged power path or an internal hardware fault. The first task is to turn those descriptions into observable, reproducible conditions.

Ask when the problem started, what changed, which users are affected and whether it occurs consistently. Include the business consequence: a malfunctioning meeting-room display is urgent before a presentation, while a spare development laptop can often be investigated more slowly. Recent updates and cable changes are useful clues, but correlation is not proof. The last action performed may be unrelated to the failure.

Record exact error messages, device models, power indicators and the results of simple tests. If the problem is intermittent, ask for the circumstances: location, temperature, battery state, workload or a particular peripheral. A consistent description of failure is often more valuable than a long list of speculative repairs.

Build hypotheses that can be disproved

A useful hypothesis predicts an observable result. If a laptop overheats, it may shut down under sustained CPU or GPU load even when disconnected from the network. If a Wi-Fi connection is failing, local offline activity should usually remain unaffected. If a power adapter lacks sufficient output, symptoms may change when the device runs on battery or with a known-good compatible charger. The objective is to choose a test that distinguishes the explanations.

Change one variable at a time where practical. A technician who updates drivers, replaces memory, changes BIOS settings and reinstalls software in one session may restore the machine without learning what caused the failure. That approach creates an unreliable support history and can introduce additional problems. Low-risk tests should come first; destructive or high-impact changes need authorization and a rollback plan.

Do not overstate diagnostic certainty. A passing memory test reduces suspicion of certain memory faults but may not catch an intermittent failure. A successful ping proves limited reachability at that moment, not that an application is healthy. Evidence narrows possibilities; it does not always eliminate every alternative.

Power and thermal failures have recognizable patterns

A computer that will not turn on raises questions about the outlet, adapter, battery, power supply and internal board. A machine that powers on but cannot complete boot presents a different path. LEDs, fan behavior, error codes and known-good suitable components can help locate the fault. Technicians should avoid opening power-supply units or manipulating swollen batteries. Safety is not an optional step to be skipped when a ticket is urgent.

Thermal problems often worsen under load. Blocked vents, failed fans, dust, incorrect cooling installation and heavy workloads can cause throttling or shutdown. A fan running at full speed is a clue, not automatic proof of a defective processor. Measuring temperatures and reviewing event information, when available, can show whether a shutdown was preceded by overheating. Power-delivery failures can create similar sudden-off symptoms, so tests should be designed to distinguish them.

An intermittent AC connection may disappear when the device is moved, while a damaged battery can fail during rapid load changes. Reproducing the failure with an approved adapter and controlled workload offers better evidence than guessing from the fact that a meeting happened to be running when power was lost.

Storage and memory symptoms overlap with software faults

Slow startup can reflect an aging hard disk, a failing SSD, inadequate memory, startup applications, file-system errors or malicious software. Audible mechanical noise, storage health indicators and repeated I/O errors are relevant, but none should be interpreted without context. If a drive might be failing, preserve data early and avoid unnecessary stress testing that could accelerate loss. A replacement plan should include backups, encryption-key handling and post-restoration verification.

Memory faults can produce blue-screen crashes, application corruption, intermittent failure to boot or problems that appear only under particular loads. Similar symptoms can arise from driver conflicts, unstable overclocking, power problems and thermal issues. Component swaps should be made with compatible parts, and a test of one slot or module should not be generalized to all components without evidence.

A device that becomes slow only while using a remote application may not be limited by local storage at all. Compare behavior when offline and during known-good local tasks. The aim is to establish which resource is constrained before ordering replacement hardware. A technician who can explain why a test rules out a class of faults saves time and avoids repeated service visits.

Printer troubleshooting starts by locating the failure stage

Printing involves application software, a queue or print service, connectivity, printer firmware, paper handling and an imaging process. A printer that produces a clean internal status page demonstrates some local mechanical and imaging functions, but it says little about whether the employee’s workstation can submit a job correctly. Conversely, a job that reaches the printer and fails during fusing points away from a purely client-side driver problem.

Regularly spaced marks on laser output can indicate recurring contact with a rotating component. Blank or faded inkjet output may reflect ink delivery or printhead behavior. Paper jams concentrated at a particular location suggest feed-path or media problems. Each print technology has different consumables and hazards, so technicians should follow the appropriate maintenance procedure rather than treating all devices alike.

Networked printers add IP addressing, driver compatibility, discovery protocols and access controls. If only one user cannot print, start at that user’s workstation and job path. If everyone sees the same failure, focus on shared infrastructure or the printer itself. A correctly scoped investigation prevents the office from losing service while unnecessary firmware changes are applied.

Separate wireless, addressing and application faults

A connected wireless icon does not prove the user has a valid route, working DNS or permission to use the requested service. Troubleshooting should establish association, address configuration, gateway reachability, name resolution and application access as separate questions. Test from a known-good device or location when authorized to compare the affected scope. If several users lose service simultaneously, seek a shared dependency before replacing every laptop’s adapter.

A host with an automatic private address may indicate failed DHCP communication, while a correct-looking address with an incorrect gateway can restrict traffic beyond the local network. A network that resolves names correctly may still be unable to connect to a particular TCP service. Understanding DNS records and how name resolution works helps a technician interpret tests without assuming every lookup error is a router failure.

Physical faults still matter. Damaged patch cables, an unstable switch port, weak wireless coverage or poor access-point power can create intermittent connectivity. A problem that follows one cable or one room narrows the possibilities. Where a network is security-controlled, obtain authorization before changing firewall settings or moving devices to a different segment just to make connectivity appear to work.

Mobile devices require an especially cautious approach

Phones, tablets and laptops often combine user data, batteries, radios and tightly integrated components in ways that restrict safe field repair. A battery that is visibly swollen, damaged or abnormally hot must be handled under approved safety procedures. Attempting to pierce or compress the pack is not an acceptable diagnostic test. Some symptoms require warranty service or component-level repair beyond the help desk’s authorization.

A mobile device that cannot charge may have a damaged cable, unsupported power adapter, contaminated connector or internal problem. A headset that will not connect may be paired to another host rather than broken. External displays may fail because a port lacks the necessary video mode. The most effective support action often comes from verifying capabilities and trying an appropriate known-good component rather than replacing the entire device.

Privacy and backup status determine what actions can be taken. A factory reset may remove user content and enrollment, so it is not a harmless universal troubleshooting step. A work-managed phone may also be subject to security policies that a local technician cannot change. Understanding authority and data protection is part of resolving the ticket safely.

Verify service restoration, not just technical symptoms

An intervention is not complete when an error disappears from the logs. A printer should print the user’s actual document. A laptop should remain stable under representative load. A wireless user should be able to access the intended authorized application. Verification should reproduce the work that failed and, where appropriate, test related functions so that the repair has not introduced another problem.

Document the initial symptom, tests, findings, change made and observed result. If a component was replaced, include its model and any follow-up requirement. If the issue could not be reproduced, state that limit rather than claiming a definitive fix. Clear records help a subsequent technician recognize recurrence or identify a broader pattern across devices.

Preventive steps should be proportionate. Cleaning blocked vents, correcting cable strain or improving printer media handling may reduce recurrence. Rebuilding the entire network because one desktop’s connector failed is not proportionate. The technician’s goal is a reliable outcome with minimal additional risk.

Professional judgment is the real troubleshooting skill

Core 1 scenarios deliberately present overlapping symptoms. That is what makes understanding power, hardware, networking and mobile support more useful than remembering isolated definitions. The exam may ask which check or action best follows the evidence, not which component is most famous for a symptom. Technicians should practice explaining why an alternative action would be premature or unsafe.

Consider the original meeting-related shutdown. A careful technician records the power events, tests under controlled local load, checks thermal evidence and uses suitable components to isolate the problem. The user receives a verified solution and an explanation. The network adapter is never replaced simply because the machine happened to be online.

The best troubleshooting process protects data, keeps people safe and turns observations into decisions. It also recognizes limits: when the fault crosses into specialized infrastructure, security policy or warranty service, an accurate escalation can be the correct resolution. Those habits matter well beyond the A+ exam because they preserve confidence in an IT team each time a device fails unexpectedly.

Continue exploring the technologies and certification concepts that matter most to you.