Core 1 is easier to master when the blueprint becomes one support workflow instead of a pile of ports, connectors, parts, and wireless standards. This guide breaks the current five-domain outline into practical support decisions, shows where to spend study time, and connects each domain to hands-on work, free practice questions, and a final-review cram sheet.
This is independently authored study material. Zeph Tech does not publish recalled, leaked, copied, or live exam questions. CompTIA's current certification page and objectives remain the authority for the exam.
Exam identity, timing, scoring, domain weights, recommended experience, and review dates are rendered from Zeph Tech's maintained certification registry.
Active
Last verified: 2026-09-25
Next review: 2026-10-25
Some objectives are about identification: connector type, storage technology, wireless band, mobile accessory, or network service. Do not stop at naming the item. Add what it connects to, why you would choose it, what compatibility constraint matters, and what symptom appears when it fails. Recognition becomes useful only when it changes the next support action.
Networking, mobile devices, virtualization, and small-office equipment contain many configuration decisions. For each one, know the intended result and the evidence that the configuration succeeded. A memorized setting is fragile; a setting tied to a traffic path, device role, or user outcome is easier to recall and easier to troubleshoot.
Core 1 gives the most weight to hardware and network troubleshooting. Study every major technology in two states: healthy and broken. Record the symptom, the first safe observation, a likely cause, a confirming test, and the final validation step. That approach makes troubleshooting a reusable method rather than a collection of one-off fixes.
A+ requires both current cores, but the emphasis differs. Core 1 centers on devices, hardware, networking, cloud and virtualization, and hardware/network fault isolation. Core 2 moves deeper into operating systems, security, software troubleshooting, and operational procedures. Keeping the outlines separate prevents your readiness score from being distorted by studying the wrong core.
The reviewed V15 Core 1 record uses 13%, 23%, 25%, 11%, and 28% across the five domains.
Mobile Devices covers laptop hardware, batteries, displays, ports, accessories, docking, connectivity, synchronization, and common mobile support tasks. The important skill is connecting an observed symptom to the smallest plausible component or configuration boundary. A charging failure, dark display, wireless problem, and account-sync issue can all be reported as a broken laptop or phone, but they belong to very different fault domains.
Study priority: inventory one laptop and one mobile device. Identify ports, radios, storage, memory, power options, display connections, cameras, authentication methods, and management settings. For each component, write one normal use case and one failure symptom. Include data-protection steps before reset, replacement, or migration so troubleshooting does not create a second problem.
Networking covers endpoint connectivity, ports and protocols, TCP/IP concepts, wireless, small-office equipment, network services, and the difference between local and upstream failures. A support technician should be able to move logically from physical or radio link through addressing, gateway reachability, name resolution, and application access instead of treating every complaint as an internet outage.
Study priority: practice with a real or simulated home/small-office network. Identify the provider handoff, router, switch, access point, DHCP service, DNS resolver, NAT boundary, and client configuration. Break one element at a time: wrong gateway, bad DNS, disconnected cable, disabled adapter, incorrect wireless credentials, or exhausted address pool. Predict the symptom before testing it.
Hardware covers motherboards, processors, memory, storage, power, peripherals, printers, cables, interfaces, and installation considerations. Do not memorize components in isolation. Tie every part to compatibility, capacity, installation, power, and failure evidence. A technically compatible component can still be a poor choice if the system lacks the right slot, connector, firmware support, power budget, cooling, or physical space.
Study priority: build a compatibility checklist. For CPUs and boards, think socket and firmware. For memory, think type, generation, capacity, speed, and channel configuration. For storage, compare interface, capacity, performance, and migration. For power, distinguish no-power, intermittent-power, battery, adapter, outlet, and load problems. For printers, connect output artifacts to likely mechanical, consumable, driver, queue, or network causes.
This domain is smaller but conceptually important. Understand what a hypervisor abstracts, how a guest depends on host CPU, memory, storage, and networking, and why a virtual machine can fail even when the guest configuration looks correct. In cloud scenarios, focus on who manages which layer and how elasticity, synchronization, virtual desktops, and remote services affect support decisions.
Study priority: create a small virtual machine. Observe its virtual processor, memory, disk, and network adapter. Change one resource and note the effect. Snapshot it, then compare that snapshot to a real backup. Disconnect its virtual network and diagnose the symptom. The purpose is not to become a virtualization engineer; it is to understand the support boundary between guest, hypervisor, host, and upstream network.
Troubleshooting is the largest Core 1 domain and should shape how you study every other domain. The exam expects a method: identify the problem, establish a theory, test it safely, plan and implement the solution, verify complete functionality, and document the result. Random replacement or restarting can restore service without proving the cause and can destroy useful evidence.
Study priority: maintain a symptom table for no boot, no display, overheating, memory instability, storage errors, slow performance, wireless drops, incorrect addressing, DNS failures, printer artifacts, cable faults, and peripheral failures. For each symptom, record the least disruptive first test and the observation that would move you to the next theory.
Allocate roughly two to three hours to Mobile Devices, four to five hours to Networking, about five hours to Hardware, two hours to Virtualization and Cloud, and five to six hours to Hardware and Network Troubleshooting. Do not spend every minute reading. Reserve at least one-third of each block for retrieval, hardware inspection, network tests, or scenario questions.
Use the extra time to build and break things. Reconfigure a small network, replace or inspect components, use a virtual machine, troubleshoot a printer, compare storage devices, inspect firmware and system information, and document your changes. The more of the blueprint you can associate with a real observation, the less you have to remember as arbitrary vocabulary.
Do not keep repeating the comfortable domain just because it produces high practice scores. Move time into networking, wireless, cloud responsibility, and troubleshooting sequence. Experienced hobbyists often know parts extremely well but have weaker operational discipline or networking evidence. The exam measures support judgment, not just component familiarity.
Give yourself extra time to understand what normal looks like. Before diagnosing failures, learn to inspect a healthy endpoint: device manager or system inventory, IP configuration, storage state, memory use, firmware information, wireless settings, printer status, and common peripheral connections. Troubleshooting becomes much easier when you have a baseline for comparison.
Choose one laptop or desktop and document CPU, memory, storage, network adapters, firmware version, display outputs, USB interfaces, power source, peripherals, and operating temperatures if available. Then write what symptom you would expect if each major component failed. This converts static hardware facts into troubleshooting evidence.
Document a client address, prefix, gateway, DNS server, wireless or Ethernet link, and route to an external service. Test local gateway reachability, remote IP reachability, and name resolution separately. Then create one controlled failure and identify it from the evidence rather than from prior knowledge of what you changed.
Inspect installed memory and storage, available capacity, health indicators, and performance. If you have spare hardware, perform a safe memory or storage replacement. If you do not, use service documentation to map the replacement steps. Add a backup and restore consideration so the lab includes user-data protection rather than treating hardware replacement as an isolated mechanical task.
Create a small guest, change CPU and memory allocation, inspect its virtual disk and network, and observe how host constraints affect it. Break network connectivity at the guest and virtual-switch level on separate attempts. The goal is to learn which evidence belongs to the guest, hypervisor, host, or physical network.
Trace the path from user application to driver, spooler or queue, network connection, and printer. Compare a software or queue failure with a physical print-quality issue. Record which symptoms point toward configuration, connectivity, consumables, feed mechanics, or imaging components. Printers become much easier once you stop treating every failure as the same category.
For every lab, record the original symptom, scope, theory, evidence, change, validation, and final state. Documentation is not separate from troubleshooting. It proves what changed, allows another technician to reproduce the result, and trains the sequence the exam expects you to follow under time pressure.
Read the current owner-published objectives from beginning to end. Mark each bullet strong, partial, or unfamiliar. Do not begin by perfecting Mobile Devices simply because it comes first. The first pass is an inventory of your knowledge, not a deep study session.
Use the full Core 1 study guide and your primary course or book to understand complete systems: a laptop, a small network, a desktop build, a printer workflow, or a virtualized endpoint. Connecting objectives inside a system reduces the number of disconnected facts you must retrieve.
Use the free Core 1 practice test to identify weak areas. For each miss, write the smallest objective-level gap you can name. "Review hardware" is too broad. "Confused memory compatibility with storage interface" or "tested DNS before confirming IP reachability" gives you a concrete remediation task.
Take common symptoms from your notes and state the next diagnostic action before looking at any options. This prevents multiple-choice recognition from doing the reasoning for you. If you cannot name a safe first test, return to the technology and learn what evidence distinguishes its common failure modes.
Use the printable Core 1 cram sheet once the material is familiar. A cram sheet is useful for reminding you of relationships you already understand; it is a poor substitute for learning an entire hardware or networking domain for the first time.
Before scheduling, compare your checklist to CompTIA's current A+ material and confirm you are preparing for the active series. Older A+ resources remain widely indexed and can be technically useful, but retired exam codes and weighting should not determine your current readiness plan.
The reviewed record above is sourced from current CompTIA material and scheduled for recurring review. Use the CompTIA A+ certification page and the owner-published objectives linked from the exam record to verify the complete outline, current exam series, policies, and any lifecycle changes.
CompTIA, A+, and related marks belong to CompTIA. Zeph Tech is independent and is not affiliated with or endorsed by CompTIA. This page paraphrases the blueprint for study planning and does not reproduce live or recalled exam content.