The most useful evidence of A+ knowledge is not a stack of flashcards. It is a support ticket that another technician can follow: a clear symptom, a plausible set of causes, observations that rule out alternatives, a safe action and a check that the user’s work actually resumed. This article treats the current CompTIA A+ pair as a way to organize those real decisions rather than as two separate lists of facts to memorize.
The retired 220-1101 and 220-1102 material can help with older device and troubleshooting examples, but it must not be presented as the exams candidates book today. The active pairing is CompTIA A+ Core 1 (220-1201) and CompTIA A+ Core 2 (220-1202). Core 1 addresses devices, networking, hardware, cloud/virtualization and hardware-network troubleshooting; Core 2 concentrates on operating systems, security, software troubleshooting and operational procedures. A service-desk incident rarely respects that division, so practice should deliberately cross it.
Open a ticket with the user’s impact, not a proposed solution
An employee says, “My laptop has no internet,” shortly before a video meeting. That is a symptom, not a diagnosis. Ask whether the issue affects a browser, the meeting application, every service, or only company resources. Determine whether other users in the same location are affected, and whether the device can reach a known local network service. An apparently failed Wi-Fi card may be a captive portal, DNS failure, expired identity token or service outage. Replacing hardware too early wastes time and may create another problem.
Record the initial state in language the next engineer can use. “VPN broken” says almost nothing; “sign-in succeeds, tunnel appears established, internal application hostname fails to resolve while public DNS works” identifies a testable boundary. Write down changes made immediately before the problem, the affected account, the device model and any error that can be captured without exposing private data. If the user can continue temporarily through an approved alternative, document it rather than improvising an unreviewed workaround.
A good initial ticket also names what cannot be tested. A remote worker may not have an Ethernet adapter, administrative rights or access to a corporate log server. That limitation is part of the evidence, not an embarrassment to hide. Escalation is more efficient when the receiving team understands exactly which observations were possible and which remain open.
Separate hardware symptoms from network and service faults
A device that loses Wi-Fi after waking can have driver, power-management, access-point roaming or network-policy problems. Begin by checking whether the radio is enabled, whether the expected network is visible, and whether an address, gateway and DNS resolver have been assigned. Compare wired and wireless behavior if an approved connection is available. Use signal strength and link status as observations, not as proof that the application path is healthy.
When a machine will not boot, protect user data before pursuing aggressive repair. Distinguish a power fault from a display fault, a firmware/boot-device problem from a filesystem failure, and a damaged drive from a corrupted OS update. Safe diagnostic steps may include known-good power, documented hardware status indicators, BIOS/UEFI detection, storage health and recovery environment checks. A technician should know when opening a device would violate warranty, safety or asset-management rules.
Core 1 knowledge is valuable precisely because it prevents software troubleshooting from starting on a faulty physical foundation. Core 2 then helps isolate configuration and operating-system behavior once a reliable device and path are established. A useful field notebook shows this sequence: hardware and link confirmed; service or identity still failing; investigation moves to the next layer. That is much more compelling than a list of randomly selected commands.
Track identity and permissions as their own fault boundary
The user reports that a shared folder has disappeared. The easy but unsafe response is to grant wide access or disable a security setting to “make it work.” Instead compare the user’s identity, group membership, resource permissions, conditional-access requirements, device compliance and the actual network path. The service may be reachable yet refuse authorization. Conversely, repeated password prompts may result from a stale session or a clock problem rather than an incorrect credential.
Identity troubleshooting requires careful privacy handling. Never request a user’s password for a ticket, and do not paste authentication tokens, personal data or sensitive configuration into a public chat or note. With authorization, use administrative logging and group membership checks to establish the policy that applied at the time of the failure. Where a conditional-access block is expected, the support action may be to explain the compliant device or access route—not to eliminate the block.
This is one reason the two active A+ cores should be studied together. Network reachability and hardware trust may be Core 1 topics, while operating-system permissions and security procedure live in Core 2. Real users only experience that “the folder will not open.” The technician must understand all the layers while respecting the limits of their role and the team’s escalation process.
Treat application failures as reproducible experiments
An accounting application crashes after the first screen on one employee’s laptop. Before reinstalling it, ask whether the same account works on another device and whether another account works on the affected laptop. Check the application and OS versions, deployment timing, error logs, available storage and dependencies. If the crash follows one user, the profile or permissions become stronger hypotheses. If it follows the device, local runtime, security software or system integrity become more plausible.
Change one condition at a time. Capture the original error, perform an approved test and record the result. An installer repair, cache reset or policy refresh may be appropriate, but each has a possible cost. Deleting caches can remove unsynchronized work; an application reset can erase local preferences; broad permission changes can undermine control. A reversible method names what is preserved, where backups exist and how to retreat if the hypothesis was wrong.
Do not mark the ticket closed the moment the application opens once. Confirm the specific task the user needed, check that required data is still present, and note any recurrence condition. If the cause appears correlated with a deployment affecting several endpoints, add the evidence to the wider incident or problem-management process. The notebook then becomes a reusable operational record rather than an isolated success story.
Handle security incidents without destroying evidence
A device displays frequent browser redirections and unexpected login prompts. A rushed technician might install multiple removal tools or clear the entire browser profile. Those actions can remove evidence, interrupt authorized accounts or mask an active compromise. First determine whether the symptoms are real, whether sensitive accounts might be affected, and whether the organization requires immediate isolation or security-team escalation.
Differentiate alert fatigue from actual indicators. A suspicious extension, altered proxy setting or unusual process does not establish guilt on its own. Correlate installation timing, signed binaries, network destinations, policy change logs and user-reported behavior. If malware or credential theft is credible, follow the incident-response playbook instead of conducting an improvised forensic investigation. Preserve chain-of-custody information and avoid unnecessary interaction with the suspect device.
Security awareness also changes ordinary repair decisions. A network certificate error is not solved by clicking through a warning; a disabled endpoint control is not an acceptable long-term performance tweak. The support technician must communicate a protective restriction as part of the service, not as an inconvenience to bypass. That judgment belongs in the notes and in any escalation, even if it means the immediate ticket cannot be marked resolved.
Show what happened during a remote-support session
Remote support increases the need for deliberate communication. Ask permission before viewing a user’s screen, explain what you intend to change, avoid exposing unrelated personal information and record when elevated tools or privileges were used. A remote connection may alter connectivity itself or create a misleading symptom, so compare behavior outside the session when necessary. Users should understand whether a fix is temporary and what to do if it fails again.
A convincing field-notebook entry is concise but complete: observed symptom, affected scope, specific tests, findings, authority for the change, exact correction, verification, user confirmation and follow-up. If you could not establish the cause, say so. An incident resolved through a reboot may still need monitoring if it recurs. Unsupported certainty is a bigger problem than a recorded unknown because it causes later responders to trust a weak explanation.
Good notes also help teams compare patterns. Five individual “printer offline” tickets might share an authentication policy or print-server dependency. A documented sequence can expose that relationship; five vague notes cannot. Escalation teams and future you benefit from reproducible evidence, especially after shifts change or a major platform update occurs.
Build a portfolio of decisions, not copied exam answers
For each practice scenario, keep a short record showing your hypothesis, the evidence that could falsify it, the safe test you chose and the recovery path. Try a DNS-only failure, a device whose hardware looks healthy but whose user profile is corrupt, an expired certificate on a test service, a mobile app that fails only over cellular, and a simulated phishing incident requiring escalation. These scenarios illustrate the breadth of Core 1 and Core 2 without pretending that either exam reduces to a memorized command list.
Version awareness matters. Use the current 220-1201 and 220-1202 objectives to check topic coverage; do not rely on booking statements, question weights or OS support references copied from 220-1101/1102. Past study notes can still supply useful exercises if they are labelled historical and checked against current device practices. Unauthorized recollections of real examination questions are a poor substitute for observable troubleshooting skills.
Ultimately, the field notebook should answer one question: could someone else trust this technician to diagnose and recover a user’s workstation safely? Strong answers include what the candidate did not change, how they protected data and identity, and how they validated the user’s outcome. That is a practical expression of A+ competence and gives a hiring manager or senior engineer something substantial to discuss beyond a passing score.