Core 2 is a practical support exam, so hands-on work should reproduce operating-system, security, troubleshooting and operational-procedure tasks in a safe environment. A Windows VM, Linux VM, phone or tablet, spare storage, a home lab account and a simple ticket template are enough to cover much of the current 220-1202 blueprint.
Lab one: build a Windows administrative-tool baseline
Open Task Manager, Event Viewer, Device Manager, Disk Management, Resource Monitor, System Information and System Configuration. Record what each tool shows on a healthy system.
A baseline helps later labs because you can compare failure state with known-good behavior.
Lab two: practice Windows command-line diagnosis
Use ipconfig, ping, tracert, nslookup, netstat, whoami, gpresult, sfc, chkdsk and robocopy in harmless scenarios. Save outputs and explain what question each command answers.
The objective is evidence collection, not memorizing switches that do not change the troubleshooting decision.
Lab three: build a small Linux support workflow
Use ls, pwd, cp, mv, rm, chmod, chown, grep, find, ps, top, df, du, ip, curl, dig, systemctl and journal-style logs in a disposable VM.
A Linux command-line lab becomes useful when you intentionally create a permission or service problem and recover it.
Lab four: configure basic endpoint security
Review Windows Firewall, Defender Antivirus, UAC, local users/groups, BitLocker where a test environment supports it, screen-lock policy and file/share permissions. Then verify effective access with a non-admin user.
Security labs should prove that the intended user can work while unauthorized access remains blocked.
Lab five: simulate malware response safely
Use an antivirus test string or vendor-provided benign simulation rather than real malware. Observe detection, quarantine and logs, then document the response process.
Practice the full workflow: identify, isolate if necessary, remediate, update protection, rescan, restore settings and educate the user.
Lab six: troubleshoot common software symptoms
Create safe faults such as a stopped service, disabled startup item, nearly full disk, bad DNS, failed application update or corrupted configuration in a disposable VM.
Start from the user symptom and collect evidence before fixing it. The point is to avoid random changes.
Lab seven: build a ticket and knowledge-base workflow
Create a ticket with user/device, symptom, impact, priority, evidence, actions, resolution and verification. If the issue is repeatable, turn the resolution into a short knowledge article.
This shows how one technician’s work becomes reusable team knowledge.
Lab eight: practice backup and recovery
Create a small dataset and perform full plus incremental/differential-style backup exercises with available tools. Restore to the original location and to an alternate path.
Record recovery time and verify file integrity. Backup is not proven until restore succeeds.
Lab nine: test scripting and remote support safely
Write a small script that gathers system information or performs a harmless repetitive task. Review it before execution and log the output. Then practice remote support with an approved lab tool and explicit user consent.
Automation and remote access should operate under least privilege and clear authorization.
Lab ten: run a blind support ticket
Have another person introduce a safe fault in a VM or use a saved broken snapshot you do not remember. Ask user-style questions, collect evidence, test one hypothesis, apply the smallest fix, verify the user’s task and document the result.
Add a Windows installation/recovery tabletop. Start with a machine that cannot boot and choose among repair, recovery environment, reinstall, image restore or clean installation. For each option, document user-data impact and prerequisites. This trains judgment without deliberately damaging a real machine.
Add a Windows edition/capability check. On a test PC or documentation set, identify whether domain join, BitLocker, Group Policy or Remote Desktop host capability is supported. Support technicians save time when they confirm edition limitations before troubleshooting a missing feature.
Add a file-permissions lab. Create two users and a shared folder, apply NTFS permissions, then test access. If you can use a network share safely, compare share and NTFS effective permissions. Restore the original state afterward and document what produced the denial.
Add a UAC and least-privilege exercise. Perform an administrative task from a standard account and observe the elevation path. Compare that with permanently granting local admin. The lab demonstrates why privileged action and privileged identity should not be the same thing.
Add a BitLocker or encryption tabletop. If hardware supports a disposable encrypted VM/disk, enable encryption and confirm recovery-key storage. Otherwise map the process and identify what happens if TPM state or authentication changes. Recovery planning matters as much as enabling encryption.
Add a browser-security lab using safe settings: clear cache/cookies, inspect extensions, review certificate warnings on a known test site, and compare private-browsing behavior. Do not bypass real certificate warnings simply to make a site work. The exercise should reinforce safe defaults.
Add a mobile support exercise. Review screen lock, OS/app updates, backup, locator, hotspot, corporate-app settings and remote-wipe concepts on a spare device. Compare what the organization can reasonably control on BYOD versus a corporate phone.
Add a full malware-response tabletop with a ticket and escalation path. Decide when to disconnect the device, what evidence to preserve, which tools to run, when reimaging is safer than cleaning, when backup data can be restored, and what user education follows.
Add an application-troubleshooting lab. Install a harmless application, change one prerequisite or configuration so it fails, then use logs, services, permissions and system requirements to isolate the cause. Do not solve it by reinstalling immediately; gather evidence first.
Add a profile/startup performance exercise. Use Task Manager, startup apps, Event Viewer and Resource Monitor on a test Windows system. Establish a healthy baseline, enable one unnecessary startup item, and observe the difference. This makes “slow computer” troubleshooting more concrete.
Add a Linux permissions/service incident. Make a web or test service fail because a config file or permission is wrong, then use systemctl, logs, file ownership and networking to recover it. This cross-links Operating Systems and Troubleshooting domains in one safe case.
Add a backup rotation exercise. Create three backup generations and simulate needing yesterday’s version rather than the newest one. This demonstrates why retention strategy matters when corruption or user error is discovered late.
Add a CMDB/asset record for your lab device. Track model, serial, owner, warranty, OS, software license, location and retirement status. Then update it after a component or OS change. Asset accuracy is operational evidence, not clerical decoration.
Add an onboarding/offboarding drill. For a new user, create account/access, assign device/software and document expectations. For offboarding, remove access, collect the asset, preserve business data, revoke remote access and update inventory. This shows lifecycle security through process.
Add one remote-support session with explicit permission. Use an approved lab tool, explain to the user what you are doing, avoid viewing unrelated data, and end the session cleanly. Remote support combines technical access with privacy and professionalism.
Add a simple PowerShell or shell script that gathers troubleshooting information and writes it to a file. Test the script on one VM, inspect the output and introduce one error path. The goal is trustworthy automation, not sophisticated programming.
Add a change-management exercise around that script. Before using it on multiple test systems, define version, scope, approval, backup/rollback, maintenance timing and validation. Automation can make a bad change faster, so process matters more as scale increases.
Add an AI-support experiment using non-sensitive lab data. Ask for a draft incident summary or command explanation, then check the facts manually. Remove any claim that cannot be proven from the evidence. This turns the current AI objective into responsible support practice.
Finish with a final practical checklist: safety, data protection, user permission, baseline evidence, hypothesis, smallest change, verification, ticket update and user communication. If every lab follows that sequence, Core 2 objectives become professional habits rather than exam-only knowledge.
Add a macOS support lab or tabletop using Time Machine, Keychain, FileVault, Spotlight, System Settings and Force Quit. Compare how the same password, backup, app or disk symptom would be investigated differently from Windows.
Add a mobile security drill that separates lost device, malware-like behavior and app configuration. Use screen lock, updates, locator, backup, MDM and remote-wipe concepts without risking personal data. Ownership and privacy should influence every response.
Add a browser and certificate exercise. Visit a trusted HTTPS site, inspect certificate details, then compare with a controlled expired/self-signed test if available. Learn to explain the warning instead of bypassing it automatically.
Add a low-disk-space incident. Fill a disposable VM enough to trigger application or update problems, then use OS tools to identify large files, logs or temporary content. Free space carefully and verify the original application or update works afterward.
Add a ticket-priority exercise. Create one low-impact single-user problem and one organization-wide security incident. Compare severity, escalation, SLA expectations and communication. Technical symptoms are only part of prioritization.
Close the lab by restoring snapshots or known-good state and cleaning temporary accounts, files, scripts and remote-access settings. Safe labs model the same discipline expected in production support.
Add one change-control lab around a system-wide setting. Propose a Group Policy, firewall or software-deployment change, document scope and rollback, test on one disposable endpoint, collect user-impact evidence and only then expand the target. The exercise demonstrates why operational procedure is a technical risk control rather than paperwork after the fact.
Add one final recovery drill where a VM snapshot or backup is restored after a deliberately bad configuration change. Confirm that the user’s application and security state are both correct after recovery. Recovery should return the system to a trusted, usable condition—not merely make it boot again.
The current A+ generation rewards exactly this behavior: structured support across OS, security and process rather than isolated memorization.