A technician who studied CompTIA A+ Core 1 several years ago may still remember the difference between an SSD and a hard disk, how DHCP assigns network settings, and why a swollen battery should never be treated as a normal laptop fault. Those are durable skills, even though the specific exam that tested them is not current. CompTIA retired English-language exam 220-1101 on September 25, 2025, as the A+ program moved from the V14 1100 series to the V15 1200 series. The retirement changes which objective document candidates should follow, not whether basic hardware reasoning remains useful.

The retired 220-1101 blueprint still shows which foundational hardware and network skills carry forward into newer A+ versions. Current candidates should study 220-1201 Core 1 and 220-1202 Core 2 as a coordinated current-version pair. The old 220-1101 and 220-1102 exams were the two parts of the same earlier A+ version; they should not be treated as independently bookable pathways today. The broader CompTIA certifications now reflect newer endpoint, cloud and security work. Understanding how the old objectives were organized is most helpful when auditing previously purchased study materials.

What V14 Core 1 measured and why that still matters

The 220-1101 outline placed 15% of scored content in mobile devices, 20% in networking, 25% in hardware, 11% in virtualization and cloud computing, and 29% in hardware and network troubleshooting. These percentages were useful for prioritizing practice, but they did not mean that a real repair incident would fit into one clean domain. Replacing a failed wireless card, for example, may involve hardware replacement, antenna connections, driver state, radio configuration, network addressing and a proof that the device can join an authorized network. The exam rewarded identifying the most plausible cause and following a sensible sequence.

The updated 220-1201 retains the broad domain structure while shifting emphasis. Networking occupies 23% rather than 20%; mobile devices 13% rather than 15%; hardware stays at 25%; virtualization and cloud stay at 11%; and troubleshooting moves to 28%. Those shifts do not turn every legacy lesson obsolete. They remind readers that current test decisions must be based on the new objective list, especially when a vendor updates supported hardware, security practices or terminology. Historical domain weights are not a substitute for reading the live exam blueprint.

Learn to classify hardware failures before replacing components

A desktop that powers off under load can have a thermal problem, a failing power supply, unstable memory or an application fault. A technician should collect the symptom pattern before opening the case. Does the failure occur at startup, only under graphics load, or after the room becomes warm? Are fans running correctly? Are there errors in hardware event logs? Does the power supply have enough capacity for the installed devices? A methodical repair isolates causes rather than swapping expensive parts until the problem disappears.

Storage and memory introduce their own clues. A system that is slow only during random reads may be waiting on a degraded disk, insufficient memory causing paging, or malware activity. SMART health data can suggest drive trouble but cannot establish that every backup is good. Replacing a disk before confirming backup integrity and encryption recovery may create a data-loss incident. Compatibility matters as well: memory generation, socket type, motherboard firmware, connector standards and laptop service constraints determine whether a nominally similar component can be fitted safely. The relationship between capability and workload remains central to appropriate hardware selection.

Mobile device repair starts with a different risk model

Laptops, tablets and phones are compact assemblies with batteries, integrated displays and limited upgrade paths. A cracked screen does not justify a battery replacement; a device that refuses to charge may have a damaged connector, cable, charger, charging circuitry or battery-management fault. When a battery is swollen, the risk is physical and immediate. A technician should stop ordinary troubleshooting and follow the manufacturer's safe handling and disposal procedure rather than puncturing, compressing or continuing to charge it. Personal data also changes the process: user consent, backups and device-management enrollment may determine what can be reset.

Wireless problems are common because mobile devices move between access points and networks. Signal strength, captive portals, authentication method, saved network profile, time settings and IP configuration are distinct variables. An employee phone that works on mobile data but not corporate Wi-Fi needs an investigation of the wireless admission path, not an assumption that the phone's radio is faulty. Enterprise mobile support may require MDM policy awareness and app ownership even at a basic level. The practical scenarios behind mobile device support remain relevant despite the exam code change.

Network troubleshooting should separate address, name and path

An endpoint may show a valid link light and still have no usable internet service. First inspect its assigned address, subnet, gateway and DNS resolver. A self-assigned address often indicates that the expected DHCP exchange failed, but it can also coexist with another working interface. A successful ping by IP with failed hostname resolution points toward a different class of issue than inability to reach the gateway. The relevant questions are what the device knows about its local network and whether packets can travel through the intended next hop.

The old Core 1 included common TCP/IP services, wireless standards, basic network equipment and small-office connectivity. That content belongs in a coherent flow, not a port-number memory contest. When a printer disappears after a router replacement, check IP addressing, VLAN placement, wireless isolation and device discovery rather than assuming the queue driver is broken. DHCP behavior and CIDR boundaries help explain why a small configuration error can isolate otherwise healthy equipment. Candidates moving to V15 should carry forward the reasoning while updating service details and platform assumptions.

When an issue spans several devices, check environmental factors before condemning individual components. A classroom full of laptops failing to charge through the same docking stations may have a power-distribution or compatibility problem; replacing every battery would be both expensive and wrong. Likewise, many printers showing the same network error suggest a shared service or configuration rather than simultaneous mechanical faults. Compare failure timing, device models, cables and configuration baselines. This is especially important for hardware support because physical part replacement can erase clues and consume stock unnecessarily.

Printers and peripheral failures are tests of workflow discipline

Laser, inkjet, thermal and impact printers operate differently; their maintenance procedures differ accordingly. A technician should distinguish streaking, misfeeds, network discovery, driver rendering and authentication errors instead of treating every print problem as a consumable issue. For example, if one application produces garbled output while test pages and other applications print cleanly, the fault may be in the driver, language or document rendering path rather than the printer engine. If multiple users cannot reach the printer but local diagnostics succeed, examine network and print-server dependencies.

Modern printers are also networked systems that hold credentials, jobs and sometimes cached documents. Replace consumables safely, verify default trays and finishing options, and record whether a device was sanitized before disposal. A support decision must preserve confidentiality as well as restore paper output. The lesson extends to docks, webcams, external storage and USB peripherals: verify the connection, power, operating-system detection and application permission in that order before concluding that the hardware itself has failed. Each step should produce an observation that narrows the problem.

Cloud and virtualization were present even in the older exam

The V14 Core 1 did not ask candidates to design complex multi-account cloud systems, but it did require recognizing service models and the role of virtualization. An organization may deliver software as a hosted service, run workloads on infrastructure rented from a provider, or use virtual machines on local hardware. These arrangements shift responsibility for software updates, operating systems, physical hardware and data protection. The support technician should know which layer the organization controls before attempting a fix. A thin client failing to reach a virtual desktop is not automatically a failed desktop computer.

A virtual machine has virtual CPU, memory, network and storage needs that still depend on underlying physical resources. Snapshotting can help during a controlled change but is not a replacement for protected backups. Virtualization may simplify hardware replacement while introducing hypervisor and shared-storage failure domains. The exact product interface changes, but these distinctions remain useful in the updated certification. A focused discussion of virtualization in everyday IT support provides one way to carry the old knowledge into present-day operational work without expanding Core 1 into a cloud architecture exam.

Make troubleshooting produce evidence and a clean handoff

A good technician starts by identifying the symptom, confirming its impact and gathering relevant changes. Hypotheses should be testable: the address is wrong, the component overheats, a cable is faulty, or a driver version introduced a regression. Replace one variable at a time when possible and use controlled comparisons. If a device is assigned to another person or business unit, establish authorization before accessing files, configuration or diagnostic logs. Security and safe handling are not paperwork after the repair; they are part of performing the repair correctly.

Once the immediate fault is fixed, verify the original workflow with the affected user and document the change, supporting observations, any parts replaced and whether further monitoring is needed. This is especially important when repairing an intermittent fault, since one successful test does not prove it has disappeared. The old Core 1 focus on structured problem-solving continues to map closely to troubleshooting with evidence. What has changed is the exam candidates must actually take. Use this historical page to understand older training and use the V15 objectives for current certification preparation.