The current CompTIA A+ certification uses Core 1 exam 220-1201 and Core 2 exam 220-1202. Core 1 emphasizes mobile devices, networking, hardware, virtualization, and hardware and network troubleshooting. Core 2 emphasizes operating systems, security, software troubleshooting, and operational procedures. SysDesks does not reproduce exam questions and is not an official CompTIA product. It gives those subjects a help desk context where a user reports a symptom, the machine and account contain evidence, and the learner has to choose a safe next action.
What these CompTIA A+ practice scenarios test
- Symptom definition and scope. A ticket rarely arrives with a diagnosis. The learner has to separate what the user observed from what the system proves, ask whether anyone else is affected, identify what changed, and choose the first check that can narrow the cause without making the situation worse.
- Tool selection. Hardware and Windows tickets can require Device Manager, Event Viewer, Services, Task Manager, Disk Management, Settings, File Explorer, the printer console, or a working command prompt. The score comes from using relevant evidence, not from opening every console until the symptom disappears.
- Networking fundamentals in context. Addressing, DHCP, DNS, gateways, routes, wireless state, and VPN behavior appear as user facing connectivity failures. Commands such as ipconfig, ping, tracert, pathping, nslookup, netstat, arp, route, and netsh read the simulated endpoint state and help the learner isolate the failing layer.
- Security and authorization judgment. Identity verification, least privilege, protected groups, suspicious messages, local administrator requests, and changes outside Tier 1 authority are treated as decisions. A technically possible change can lose points when the request does not authorize it.
- Operational procedure. Ownership, communication, change control, verification, work notes, resolution codes, and escalation evidence all contribute to the outcome. Closing a ticket with the symptom gone but no verification or usable notes is incomplete support work.
Ticket practice complements A+ study because it forces several objectives to interact. A learner may know that an APIPA address begins with 169.254, but a support ticket asks what that evidence rules in, what it rules out, whether a renewal is safe, what result should be verified next, and when the fault belongs with network operations. The simulator makes that sequence visible without pretending to replace an official objective list, a full course, or a timed practice exam.
Core 1 hardware and networking scenarios
- Hardware symptoms include a laptop battery that will not charge, an external monitor that is not detected, storage pressure, slow startup, printer jams, spooler failures, driver problems, and replacement hardware requests. The learner must distinguish a physical symptom from a configuration or service fault before replacing anything.
- Printer practice includes endpoint queues, drivers, default printer selection, the Windows spooler, network reachability, and a simulated printer front panel. That supports the Core 1 expectation that a candidate can troubleshoot printer symptoms while also practicing the service desk evidence and communication that an exam outline cannot simulate by itself.
- Network scenarios include APIPA addresses, failed DHCP renewal, wrong DNS servers, internal names that fail while IP connectivity works, default gateway problems, wireless configuration, VPN paths, and network side faults. The learner can compare ipconfig output, ping a gateway, test a known IP, query a name, and decide where the fault actually sits.
- Mobile and peripheral tickets cover charging, connectivity, displays, sound, and approved replacement workflows. SysDesks focuses on support diagnosis and documentation. It does not claim to reproduce every physical assembly task or every Core 1 hardware objective inside a browser.
Core 2 operating system and security scenarios
- Windows scenarios use Task Manager, Services, Event Viewer, Windows Update, Device Manager, Registry Editor, Disk Management, Computer Management, Local Users and Groups, Credential Manager, and command line tools. Ticket state changes when the learner stops a process, changes a service, repairs system files, manages storage, or corrects an approved setting.
- Software troubleshooting covers applications that fail to start, installations blocked by privilege, update failures, damaged system files, cached credentials, startup load, disk pressure, and services that are stopped or misconfigured. Evidence must support the chosen fix, and a restart without diagnosis can be penalized.
- Security practice includes phishing reports, suspicious sign ins, identity verification, password and lockout handling, local administrator requests, least privilege, protected actions, and escalation. The expected behavior is often to preserve evidence and involve the correct team rather than to take the most powerful action available.
- Operational procedure appears throughout the queue. The learner records what the user reported, what was checked, what changed, how the result was verified, and what another technician would need if the problem returned. This aligns with the Core 2 emphasis on documentation, communication, safety, professionalism, and change handling.
Map each scenario to the current A+ objectives
| Objective or domain | SysDesks scenario | Tool | Evidence | Score |
|---|---|---|---|---|
| 220-1201 Networking | APIPA address and failed DHCP response | ipconfig, ping, nslookup | Address, gateway, lease, IP reachability, and name resolution | Diagnosis, safe fix, and verification |
| 220-1201 Hardware | Battery, display, storage, and printer faults | Device Manager, Settings, Disk Management, printer console | Device state, capacity, driver, service, and front panel status | Relevant checks and correct remediation |
| 220-1201 Hardware and network troubleshooting | Slow startup, DNS failure, VPN path, and printer jam | Task Manager, Event Viewer, terminal, network and printer tools | Measured symptom before and after one controlled change | Cause, fix, and proof |
| 220-1202 Operating Systems | Windows service, update, process, storage, and account tickets | Services, Windows Update, Task Manager, File Explorer, command prompt | System state, logs, command output, and user retest | Technical result and process |
| 220-1202 Security | Phishing, lockout, privilege, and access requests | Mail, directory, event evidence, communication | Identity, authorization, indicators, and preserved evidence | Safety and escalation judgment |
| 220-1202 Software Troubleshooting | Application crash, failed install, cached credential, and system file damage | Event Viewer, software console, sfc, dism, tasklist, taskkill | Error, process, deployment, and repair state | Diagnosis before remediation |
| 220-1202 Operational Procedures | Every resolved or escalated ticket | Queue, calls, mail, knowledge base, work notes | Ownership, updates, verification, notes, and resolution code | Communication, documentation, and handoff |
Commands and tools used in the scenarios
- Networking evidence can come from ipconfig, ping, tracert, pathping, nslookup, netstat, arp, route, getmac, nbtstat, and netsh. A command runs against the simulated machine rather than returning one fixed training transcript, so a changed adapter or route changes the result.
- Windows evidence can come from systeminfo, tasklist, taskkill, sc, driverquery, sfc, dism, chkdsk, diskpart, findstr, and graphical management consoles. The correct tool depends on the symptom. A driver problem and a stopped service should not be worked through the same checklist merely because both affect Windows.
- Identity evidence can come from whoami, net user, net group, dsquery, gpupdate, gpresult, the directory tree, group membership, account state, and sign in activity. The learner still has to verify the requester and determine whether the requested change is delegated to Tier 1.
- Communication and documentation are tools as well. Calls, mail, chat, the knowledge base, work notes, escalation records, and resolution codes establish whether the technical work was understood, authorized, confirmed, and handed over properly.
How each ticket is scored
- Technical accuracy checks whether the diagnosis matches the simulated fault, whether the chosen action changed the required state, and whether the endpoint, account, network, or printer now satisfies the ticket's resolution conditions.
- Process scoring checks ownership, relevant investigation, safe sequencing, knowledge use, verification, and escalation. Random changes, repeated restarts without evidence, or broad fixes that exceed the request can reduce the score even if the final symptom disappears.
- Communication scoring checks identity verification where required, expectation setting, clear updates, confirmation with the user, and advice that prevents recurrence. Some callers are impatient or misleading, so the learner has to stay precise without surrendering the security boundary.
- Documentation scoring checks whether the work note identifies the symptom, evidence, action, and verified result. A useful note lets another technician understand what happened without replaying the entire ticket or accepting an unsupported conclusion.
Practice scenarios and practice tests serve different purposes. A practice test estimates recall and exam readiness under question based conditions. A scenario trains the workflow that starts after a user says something is broken. SysDesks should be used alongside the official objectives and reputable study materials. It does not contain real exam questions, memorized exam content, or dumps, and completing a scenario does not predict an A+ score.
Complete worked scenario
- Read the ticket: a workstation cannot reach websites and the user reports that everything worked yesterday. Establish whether only one device is affected and confirm the employee before opening a remote session.
- Run ipconfig /all. The adapter has a 169.254 address and no usable default gateway, which identifies an APIPA state and points to a failed DHCP lease rather than a browser or DNS only problem.
- Use a controlled renewal with ipconfig /renew. Do not disable the firewall or assign an invented static address merely to make one test pass. If renewal repeatedly fails, capture the output and escalate the DHCP or relay fault.
- Verify more than the icon. Confirm the adapter no longer has an APIPA address, ping the expected gateway or a known IP, and use nslookup against the internal portal so both network reachability and name resolution are proven.
- Ask the employee to retry the original task. Then write a work note that records the APIPA evidence, renewal, new lease, gateway and name tests, user confirmation, and resolution code.