CompTIA 220-1202: Windows Administration

Windows administration appears throughout the 220-1202 Operating Systems domain: editions, installation and upgrades, administrative tools, command-line utilities, settings, networking, accounts, policy, applications, and troubleshooting. Core 2 does not turn A+ into a Windows Server certification, but it does expect a support technician to manage a modern Windows endpoint confidently.

For the live CompTIA 220-1202 exam, the most useful preparation is to learn Windows as a set of administrative questions. Which tool shows the evidence? Which setting owns the behavior? Which change is safe and reversible? Which feature depends on the Windows edition? That is more durable than memorizing menu paths that can move between releases.

Edition awareness prevents impossible troubleshooting paths

Windows Home, Pro, Pro for Workstations, and Enterprise differ in management, security, and hardware capabilities. Core 2 highlights practical differences such as domain joining, RDP hosting, BitLocker, Group Policy editing, and hardware limitations.

A technician should confirm the edition before assuming a missing feature is broken. A user may ask to join a Home edition device to a corporate domain or host an RDP session where the edition does not support it. No registry tweak should be the first answer to a product limitation.

Windows 10 and Windows 11 can both appear where supported and relevant. Focus on capability and support reasoning rather than memorizing cosmetic interface differences.

MMC and administrative consoles provide structured views of system state

Microsoft Management Console snap-ins and related tools are central to Core 2. Event Viewer provides logs, Disk Management handles local storage, Task Scheduler manages scheduled work, Device Manager exposes hardware and drivers, Certificate Manager handles local certificates, Local Users and Groups manages local identity, and Performance Monitor supports performance evidence.

The exam can present several plausible tools. Choose the one that directly answers the question. Device Manager is better for a driver problem than Registry Editor. Event Viewer is better for a service failure timeline than Disk Cleanup.

Read-only observation usually comes before change. Good administration gathers evidence first, then chooses the smallest correction that addresses the proven problem.

Task Manager and Resource Monitor turn vague performance complaints into evidence

Task Manager exposes processes, startup applications, users, services, and high-level performance. Resource Monitor adds detail across CPU, memory, disk, and network activity. Together they help distinguish a resource bottleneck from a general user complaint that “Windows is slow.”

Look for sustained patterns rather than one instant spike. A process that briefly consumes CPU during an update may be healthy. A process that grows memory continuously or saturates disk for long periods deserves investigation.

Startup configuration is another common support lever. Disabling an unnecessary startup application can improve sign-in time, but security agents and business-critical tools should not be removed simply to make metrics look better.

Command-line tools are fast when you know the administrative question

Core 2 includes cd and dir for navigation; ipconfig, ping, netstat, nslookup, net use, tracert, and pathping for networking; chkdsk, format, and diskpart for storage; file-management commands such as robocopy; informational commands such as hostname, net user, winver, and whoami; and OS-management commands such as gpupdate, gpresult, and sfc.

Each command has a scope. gpresult helps answer what policy reached the computer or user. sfc addresses protected system-file integrity. nslookup answers DNS questions. diskpart can make destructive storage changes and therefore requires more caution than an informational command.

For broader automation context, PowerShell for IT automation shows why modern Windows administration increasingly combines interactive support with repeatable scripted actions.

Settings and Control Panel areas map user symptoms to configuration owners

Windows exposes network, privacy, account, app, update, device, sound, power, indexing, firewall, mail, File Explorer, accessibility, time and language, and personalization settings. A support technician needs to know the category that owns the behavior, not every click sequence by memory.

Power options illustrate the value of context. Sleep, hibernate, fast startup, lid action, and USB selective suspend can create symptoms that users interpret as crashes, hardware faults, or battery problems. Checking the relevant setting can be safer than replacing components.

Privacy and security settings require care. Disabling a control can make an application work while violating policy. The fix should satisfy the user requirement without silently weakening the endpoint.

Windows networking administration begins at the client but crosses identity and policy

Core 2 includes IP addressing, DNS, subnet mask, gateway, static versus dynamic configuration, VPN, wired and wireless access, proxy settings, public/private network profiles, shared resources, mapped drives, and local firewall settings.

Troubleshooting starts by identifying which layer fails. If IP connectivity works but names do not resolve, DNS becomes a leading hypothesis. If a share path resolves but access is denied, identity or permission becomes more likely. If an application fails only on a public network profile, local firewall policy may be involved.

Domain versus workgroup context matters because authentication and management expectations differ. A device in a managed domain may receive policy that overrides a local change, so local evidence must be interpreted in the organizational context.

Local users, groups, privileges, and Group Policy shape endpoint access

Local accounts and groups determine permissions on standalone or locally managed systems. Domain environments extend identity and policy beyond the individual machine. Group Policy can configure security, applications, desktop behavior, networking, and many other settings centrally.

gpupdate requests policy refresh and gpresult helps show the applied result. Those are different actions. If a setting keeps returning after a local change, centrally managed policy may be the reason.

Least privilege should guide administration. Routine users should not receive unnecessary administrative rights just because an application is inconvenient. Solve the underlying compatibility or deployment issue rather than normalizing permanent elevation.

Updates, drivers, and application changes need rollback thinking

A support technician regularly installs updates, features, drivers, and applications. Every change can solve one problem and create another. Before significant changes, understand compatibility, recovery options, user data, and the organization’s change process.

Driver rollback, application repair, system restore, update removal, or recovery environments can be safer than reimaging. The correct option depends on what changed and what evidence links the change to the symptom.

In managed environments, even endpoint changes can require change-management discipline. Timing, impact, approval, communication, validation, and rollback planning are operational controls, not paperwork added after the technical work.

Scripting is useful because repeatability reduces human error—when it is controlled

Core 2 names script types such as batch, PowerShell, VBScript, shell, JavaScript, and Python and associates them with automation tasks such as restarts, drive mapping, application installation, backup, data collection, and updates.

Scripts create leverage, which means they can also create large mistakes quickly. A poorly tested script can change settings across many machines, consume resources, or introduce untrusted code. Use trusted sources, version scripts, test on limited scope, log outcomes, and understand how to stop or roll back the action.

At A+ level, the goal is not advanced software development. It is recognizing when automation is appropriate and treating a script as a controlled administrative change rather than a magic shortcut.

Administration is complete only when the user’s service is verified

After changing Windows, verify the original user need plus surrounding controls. If the task was to fix a mapped drive, confirm the user can access the required resource under normal credentials. If the task was to repair an application, confirm launch, update, data access, and security state.

Document what was observed and what changed. That creates continuity for the next technician and gives the organization evidence if the issue returns.

Windows administration in 220-1202 is therefore less about being able to find a setting once and more about making controlled, evidence-based endpoint changes safely.

Practice by assigning every symptom to a tool, scope, and verification step

Build short scenarios: a service will not start, DNS names fail, a device driver broke after update, a user cannot edit a local policy, a mapped drive disappears, or a machine boots slowly. For each, choose the evidence tool, likely configuration scope, safe change, and verification.

That exercise joins the many Windows objectives into one administrative workflow and prepares you for scenario questions far better than memorizing isolated definitions.

Windows administration questions are easier when tools are grouped by the kind of state they manage. Computer Management and related consoles expose local system configuration; Task Manager and performance tools show runtime state; Event Viewer provides evidence; Disk Management changes storage; Services controls background components; Device Manager manages hardware and drivers; local users, permissions, and policy tools control access. Memorizing names without understanding the state each tool owns leads to poor troubleshooting choices.

Command-line administration should follow the same principle. Use a command because it answers a question or makes a controlled change, not because it appears on a memorized list. Network commands help validate addressing, name resolution, routes, and sessions. File-system commands inspect or manipulate files and permissions. System commands expose processes, services, disks, or configuration. PowerShell becomes valuable when the task needs structured output, repeatability, or automation rather than a one-time manual action.

Administrative work also needs a safety boundary. Before changing services, startup behavior, accounts, permissions, partitions, or security settings, identify the expected effect and a recovery path. After the change, verify the original objective rather than assuming that an error-free command means the system is healthy. That evidence-first approach connects Windows administration directly to the troubleshooting and operational-procedures domains.