CompTIA A+ Study Guide: Hardware, Networks, Operating Systems, and Troubleshooting

CompTIA A+ Core 1 starts with computer hardware, but the useful skill is understanding dependencies. The CPU executes instructions; RAM holds active working data; storage preserves files without power; and the motherboard connects components through buses and controllers. Firmware initializes the platform before handing control to a bootloader. Compatibility depends on more than physical fit: a processor must match the socket and supported firmware, while memory must match the board’s generation and configuration requirements. Likewise, M.2 describes a form factor, not a guaranteed storage protocol: an M.2 device may use SATA or PCIe/NVMe, and the slot must support it.

Suppose a desktop powers on but shows no image after a RAM upgrade. Begin with the monitor’s input selection, cable, and appropriate graphics output, then inspect diagnostic LEDs or beep codes using the system documentation. Before reseating memory, shut down, disconnect power, and follow electrostatic-discharge precautions. Test one supported module in the recommended slot, then restore the original configuration if necessary. This isolates compatibility, seating, slot, and module faults without replacing the motherboard prematurely. Never open a power supply: internal capacitors can retain hazardous energy even when it is unplugged.

Network protocols explain how a working physical connection becomes a usable service. Ethernet and Wi-Fi provide local connectivity; IP supports addressing and routing; TCP provides a reliable, ordered byte stream; and UDP sends datagrams without equivalent delivery guarantees. DNS resolves names, while DHCP commonly supplies an address, subnet mask, gateway, and DNS settings. Common port associations include DNS on 53, HTTPS on 443, and RDP on 3389. These are diagnostic clues, not proof of application identity or safety. HTTPS commonly uses TCP, while HTTP/3 uses QUIC over UDP, usually on port 443.

Consider a Windows workstation with address 192.168.10.25, mask 255.255.255.0, and gateway 192.168.10.1. Another 192.168.10.x host is normally local; traffic to a different subnet goes through a router. Run ipconfig /all to inspect settings, then test the gateway, a known reachable remote IP, and name resolution with nslookup. If remote IP connectivity works but DNS queries fail, investigate DNS rather than replacing the adapter. An unexpected 169.254.x.x address often suggests failed DHCP configuration. Remember that blocked ICMP can make ping fail even when a service works; test the actual application connection too.

CompTIA A+ Core 2 covers operating systems as managed environments, not merely desktop interfaces. The kernel manages resources such as memory, processor time, and device access. Applications generally run in user mode and request privileged services through operating system interfaces. Drivers connect the operating system to hardware, making compatibility and trusted distribution important. In Windows administration, Task Manager reveals resource use, Device Manager exposes device status, Services manages background components, and Event Viewer records diagnostic events. Linux and macOS use different tools, but the same questions apply: what is running, what changed, and which permissions govern access?

Suppose an application stops launching after an update. Record the error and timing, inspect relevant application logs, and determine whether the failure affects one user or the whole machine. A test account can help distinguish profile-specific configuration from a system-wide problem. Check storage capacity, dependencies, and supported versions before reinstalling. Use an approved rollback when evidence links the fault to a change. Windows tools such as SFC check protected system files, but they are not universal application repair utilities. Before partitioning, reinstalling, or altering encryption settings, verify backups and the authorized recovery process; a restore point is not a complete data backup.

Peripheral troubleshooting begins by locating the failure boundary. If a network printer produces its internal test page but not a Windows test page, its basic print mechanism works; investigate connectivity, the queue, port configuration, and driver. If Windows printing works but one application fails, focus on application settings or document rendering. Laser printing involves charging, exposing, developing, transferring, fusing, and cleaning; recurring marks can indicate a rotating component, while poorly bonded toner can implicate fusing or unsuitable media. Follow manufacturer procedures and allow hot components to cool. Inkjet nozzle-cleaning routines address a different mechanism and should not be treated as a universal printer remedy.

For mobile devices, check power, connectivity, enrollment status, application permissions, and account synchronization before considering a reset. A swollen lithium-ion battery is a safety issue: stop using the device and follow approved handling procedures. Virtual machines provide a practical way to study these environments without repeatedly rebuilding physical computers. A hypervisor allocates host CPU, memory, storage, and networking to guests. NAT networking usually supports outbound access through the host, whereas bridged networking places the guest on the surrounding network. Snapshots support lab rollback but do not replace independent backups. Cloud-hosted machines apply similar ideas, although responsibility depends on the service model.

Endpoint security is a layered operating practice: patch systems, limit privileges, use multifactor authentication where supported, maintain protective software, and protect recoverable backups. Authentication establishes identity; authorization determines what that identity may do. A standard user account reduces the consequences of everyday mistakes, while an administrative account should be used only for approved privileged work. Disk encryption protects data at rest, particularly on lost devices, but does not prevent an attacker from reading data through an already compromised, unlocked session. Store recovery keys according to organizational policy rather than improvising a location during an emergency.

Imagine a user reports unexpected browser extensions and repeated credential prompts. Stop unnecessary interaction and follow the incident procedure, including network isolation when appropriate. Record symptoms and timing without copying sensitive data into ordinary tickets. Do not immediately wipe the device or run arbitrary cleanup tools: either action may destroy evidence or violate response procedures. Escalate suspected compromise to the responsible team. Recovery can involve approved scanning, reimaging from a trusted source, and credential or session remediation from a clean device. Afterward, verify functionality and investigate the entry point rather than treating disappearing pop-ups as proof that the incident is resolved.

Professional hardware troubleshooting follows a disciplined sequence: identify the problem, form a probable-cause theory, test it, plan and implement a solution, verify full functionality, and document the outcome. Before changing anything, ask about scope, recent changes, reproducibility, and business impact. An intermittent slowdown affecting everyone differs fundamentally from one user’s failed login. Favor low-risk, reversible tests and alter one variable at a time when practical. Obtain approval for disruptive changes and define a rollback path. When evidence contradicts the theory, revise it rather than stacking additional changes onto an unproven assumption.

For example, a laptop disconnects only in one meeting room. Compare another device in that room and test the affected laptop elsewhere. If several devices fail in the same location, investigate coverage, interference, access-point capacity, or upstream connectivity rather than reinstalling one laptop’s driver. Record signal observations, timestamps, affected access points, and test results for escalation. Help desk ticketing should capture the reported symptom, impact, environment, evidence, actions, approvals, and verified resolution. Write 'connection remained stable during a 20-minute video call in the affected room' rather than simply 'fixed.' Never record passwords, private keys, or unnecessary personal information.

Build a small, authorized lab with a spare computer or virtual machine, test accounts, and recoverable data. Practice identifying components, installing an operating system, creating users, configuring permissions, reviewing logs, and documenting changes. Then introduce controlled faults: configure an incorrect DNS server, stop a nonessential lab service, or remove a test user’s folder access. Predict the symptom before testing it. This develops the connection between mechanism and observation that both performance-based questions and real support work require. Never simulate faults on production systems without explicit authorization and an approved change plan.

Use Erudex’s dual-track structure to connect Core 1 infrastructure with Core 2 administration. For every lab, produce a short ticket containing the symptom, hypothesis, evidence, remedy, and verification. Maintain an objectives checklist and classify each item as something you can explain, configure, or troubleshoot. Reading alone rarely establishes all three abilities. Because this course names retired examinations, map its lessons against the current 220-1201 and 220-1202 objectives and fill identified gaps. Plan both required exams within the same supported series; do not assume a retired-series pass can be combined with a successor-series exam.