CompTIA 220-1202: Objectives and Skills

CompTIA A+ Core 2 220-1202 is the software, security, troubleshooting, and operational half of the current A+ series. CompTIA’s official blueprint weights Operating Systems and Security at 28% each, Software Troubleshooting at 23%, and Operational Procedures at 21%. That relatively even distribution means candidates cannot safely treat any domain as a small afterthought.

The live CompTIA 220-1202 exam should be approached as a support-role blueprint. It asks whether you can install and administer multiple operating systems, apply endpoint security, diagnose software and security symptoms, and work within professional support processes. The broader set of CompTIA certifications provides context, but 220-1202 preparation needs to stay close to the Core 2 tasks rather than drifting into networking or hardware topics owned by Core 1.

The domain weights reward balanced preparation

Operating Systems and Security each account for 28% of the published blueprint. Software Troubleshooting contributes 23%, and Operational Procedures 21%. Only seven percentage points separate the largest and smallest domain. A study plan that spends almost all its time on Windows commands while neglecting customer support, change control, backups, or security is misaligned with the exam.

The weighting also changes how you should interpret weaknesses. A candidate who is excellent at security but weak across operating systems and troubleshooting still has a large readiness gap. It is better to build a minimum practical competence across every domain and then deepen the areas that produce the most errors in scenario practice.

Because many objectives begin with “given a scenario,” the exam is not just asking what a tool is called. It is asking when to use it, what evidence it provides, and what action is appropriate next.

Operating Systems means deployment, administration, tools, and multiple platforms

The Operating Systems domain covers Windows, Linux, macOS, Chrome OS, mobile platforms, filesystems, lifecycle limitations, installation and upgrade methods, and application requirements. Windows receives substantial operational depth through editions, administrative tools, command-line utilities, settings, and client networking.

Candidates should be able to connect a symptom or task to the right administrative surface. Event Viewer is useful for event evidence; Disk Management changes local storage configuration; Task Scheduler controls scheduled tasks; Device Manager deals with devices and drivers. Command-line utilities such as ipconfig, netstat, nslookup, chkdsk, diskpart, gpupdate, gpresult, and sfc answer different support questions.

Linux and macOS are not there as trivia. A support technician should recognize common directories, package and filesystem tools, permissions, networking commands, and platform-specific utilities well enough to perform or explain routine support work.

Security is endpoint behavior, identity, hardening, and safe user practices

The Security domain includes physical and logical access controls, authentication, least privilege, secure configuration, malware threats, workstation security, browser security, wireless considerations, mobile-device controls, and small-office security. It expects candidates to combine preventive controls with support judgment.

For example, multifactor authentication, PAM, SSO, ACLs, and device-management controls all address access, but they solve different parts of the problem. A technician should know which control protects identity, which restricts privilege, and which applies policy to endpoints.

Security also appears inside troubleshooting. Pop-ups, redirection, fake antivirus warnings, altered files, update failures, or unusual network behavior can be support symptoms with a security cause. Do not study the Security and Troubleshooting domains as if they never overlap.

Software Troubleshooting tests diagnosis across Windows, mobile, and security symptoms

CompTIA explicitly names Windows symptoms such as BSODs, degraded performance, boot failures, shutdowns, failed services, application crashes, low memory, instability, missing operating systems, slow profiles, and time drift. Mobile troubleshooting adds update, installation, responsiveness, reboot, battery, and connectivity issues.

The important skill is moving from symptom to evidence. A boot problem suggests a different first set of checks than a service that will not start. Slow performance can involve memory, storage, startup applications, malware, or background services. Randomly applying repairs risks destroying the evidence that would have identified the cause.

Security-related symptoms also demand containment judgment. If the system appears compromised, preserving data and limiting further exposure may matter more than immediately returning the device to normal use.

Operational Procedures is where technical work becomes professional support

Operational Procedures includes ticketing, asset and configuration information, change management, workstation backup and recovery, safety, environmental controls, privacy, licensing, incident handling, professional communication, scripting, remote access, and AI concepts. It is broad because support quality depends on process as much as technical skill.

The change-management process is a good example. A change should have purpose, scope, timing, impact and risk analysis, approval, implementation steps, review, and user acceptance where appropriate. The exam expects a technician to recognize why a technically correct change can still be operationally wrong if it bypasses governance.

Similarly, a backup is not just a file copy. Candidates should distinguish full, incremental, differential, and synthetic full approaches, understand rotation and 3-2-1 concepts, and know that backup testing is part of recovery readiness.

Windows tools are best learned by the question they answer

Memorizing tool names is less effective than mapping each tool to an administrative question. “Which process is consuming memory?” suggests Task Manager or Resource Monitor. “What system event occurred before the crash?” suggests Event Viewer. “Which policy settings reached this device?” suggests gpresult. “Are protected system files corrupted?” suggests sfc.

That same logic applies to command-line work. ipconfig reveals client IP configuration, nslookup checks DNS resolution, netstat shows network connections, chkdsk examines filesystem integrity, and diskpart manages partitions. The exam can combine the tool with a scenario where several commands are plausible.

For scripting context, PowerShell as an IT automation tool is useful background, but Core 2 expects basic support use cases and risks rather than advanced automation engineering.

Troubleshooting questions reward sequence and evidence, not aggressive repair

When several answers could eventually fix a symptom, the best exam choice is often the one that follows a controlled support sequence. Clarify the symptom, establish what changed, collect evidence, test a reasonable hypothesis, apply the least disruptive correction, verify full functionality, and document the result.

This protects against two common mistakes: changing too many variables at once and treating the first plausible cause as proven. If a service fails after an update, rollback may be appropriate, but checking the service state and event evidence first can reveal whether the update is actually related.

Verification should include the original user requirement. A device that boots after repair is not fully fixed if the application, network connection, or security control the user needed is still broken.

Use scenario practice to connect domains instead of drilling them separately forever

Real support cases cross the blueprint. A user cannot access a cloud productivity application: the root cause could be local networking, identity, browser settings, licensing, an update, or a policy. A slow workstation could be an operating-system issue, startup configuration, malware, or a failing application.

Once you have learned each domain, practice mixed scenarios that force you to classify the problem before choosing a tool. Explain why the wrong answers belong to another layer. That habit is more transferable than memorizing one answer key because the exam can change the surface details while testing the same support judgment.

Readiness means you can explain the next safe action

The strongest 220-1202 preparation is practical and verbal. For each objective, be able to say what the component or process does, when it applies, what evidence you would gather, what risk a change introduces, and how you would verify success. That covers both knowledge and scenario reasoning.

Use the official domain weights to keep study balanced, but let practice results determine where extra time goes. The exam is designed around the behavior of an entry-level IT support professional. If your preparation consistently asks “what would a careful technician do next, and why?” you are studying the blueprint at the right level.

Use the published domain weights to control revision time, but do not study them as four isolated boxes. A Windows troubleshooting scenario can require operating-system knowledge, security judgment, and operational documentation at the same time. The strongest practice therefore mixes objectives after the first learning pass. That cross-domain practice also improves performance on scenario questions where several technically plausible actions differ mainly in sequence or risk. For example, diagnose a startup problem, decide whether malware or an update is relevant, choose a recovery tool, document the change, and explain what evidence proves the system is stable again.

Build a simple readiness matrix from the objective document. For every bullet, mark whether you can identify the concept, explain when it matters, perform or describe the task, and troubleshoot a failure. A topic should not be considered complete because you recognize its name. If you cannot distinguish two similar Windows tools or explain why one recovery option is safer than another, return to hands-on practice.

Performance-based readiness also benefits from sequencing. Practice navigating settings, interpreting command output, and choosing the next troubleshooting step without relying on one memorized interface path. Windows versions and menus evolve, but the administrative intent—inspect, configure, verify, recover—remains stable. That is the level of understanding the exam objectives are designed to test.

Before calling this domain ready, explain how one symptom can cross operating-system, security, troubleshooting, and operational-procedure boundaries. That cross-domain explanation is a better readiness signal than recalling an isolated objective label.