Core 1 is designed around practical entry-level support, so hands-on work should touch hardware, networking, mobile devices, virtualization/cloud, peripherals, and troubleshooting. You do not need an enterprise lab. One spare PC or laptop, a SOHO router, a printer or virtual printer, a phone/tablet, a Type 2 hypervisor, and inexpensive network tools can cover a large part of the current 220-1201 blueprint.
Lab one: inventory and reassemble a PC safely
Identify motherboard form factor, CPU/socket, DIMM slots, storage interfaces, M.2 slot, PCIe slots, power connectors, cooling, front-panel headers, TPM/Secure Boot settings, and expansion cards. Practice ESD-safe handling and cable management.
Take photos or notes before removing parts so reassembly becomes a documented process rather than memory.
Lab two: create safe hardware troubleshooting symptoms
Use non-destructive changes such as disconnecting a data cable, reseating RAM in a powered-off test system, selecting the wrong display input, or disabling a boot option. Predict the symptom before starting the machine.
Then restore one component at a time and verify full functionality. This builds the cause-and-evidence thinking used throughout Domain 5.
Lab three: compare storage and RAID behavior
Install or inspect SATA and NVMe storage, review S.M.A.R.T. health, benchmark basic read/write behavior, and create software RAID in a disposable lab if available. Simulate a missing drive only in a safe environment.
Document what a healthy drive, degraded array, and missing boot device look like to firmware and the operating system.
Lab four: build a small SOHO network
Configure private IPv4 addressing, DHCP, a reservation, DNS settings, default gateway, Wi-Fi SSIDs, and separate bands where available. Identify router, switch, AP, firewall, NIC, and PoE roles.
A basic IPv4 exercise should include APIPA so you recognize what a client looks like when DHCP fails.
Lab five: practice network tools and fault isolation
Use a cable tester or loopback device where available, inspect link lights, use a Wi-Fi analyzer, verify addresses, and trace whether the failure is physical, wireless, DHCP, DNS, gateway, or remote service.
Create one case with valid Wi-Fi but bad DNS and one with no DHCP. The symptoms should feel different after the lab.
Lab six: support a mobile device
Pair Bluetooth, connect Wi-Fi, create a hotspot, inspect SIM/eSIM and location settings, review battery health, test camera/microphone, use a dock or USB-C accessory if available, and explore MDM/BYOD concepts through documentation or a demo tenant.
Practice distinguishing physical damage, charging failure, application issue, malware symptom, and network problem.
Lab seven: create a virtualization sandbox
Install a Type 2 hypervisor on a capable host, create a VM, assign CPU/RAM/storage/network, take a snapshot if supported, and compare bridged/NAT-style networking. Then run a simple container separately if practical.
A virtualization/cloud foundation should make it clear why VMs, containers, VDI, and cloud services solve different support problems.
Lab eight: deploy and maintain a printer
Install a printer or virtual network printer, choose the correct driver, connect through USB or network, configure duplex/tray settings, share it where appropriate, and test scanning or MFP features.
Then clear a queue problem, simulate wrong paper/tray settings, and review maintenance steps for the printer technology you have access to.
Lab nine: create display and cable faults
Compare HDMI, DisplayPort, USB-C video, and adapters. Change input source, resolution, refresh rate, or cable where safe. Observe symptoms such as blank output, incorrect resolution, audio loss, or intermittent display.
The goal is to separate source, cable/adapter, display setting, GPU/output, and display-panel problems.
Lab ten: run a blind support ticket from symptom to verification
Have another person choose one safe fault or use a saved scenario you do not remember. Ask user-style questions, define the symptom, inspect evidence, test one theory, apply the smallest fix, confirm the original task works, and document the result.
Add a laptop teardown or service-manual exercise even if you do not open the device. Identify where battery, RAM, storage, Wi-Fi card, antenna, webcam, microphone, keyboard, and display assemblies are located. Understanding physical layout helps with symptoms such as weak wireless after screen repair or a nonfunctional camera cable.
Add a PSU calculation and connector check. List CPU, GPU, drives, fans, and motherboard power needs in a sample build and select an appropriate PSU with enough wattage and connectors. Then identify 24-pin/20+4 and CPU/GPU power connectors physically or from a parts diagram.
Add a cable-termination exercise using spare Ethernet cable if available. Practice T568A/T568B, crimp or punchdown, then verify with a cable tester. The value is not professional cabling speed; it is understanding what continuity and pinout failures look like.
Add a DNS/DHCP troubleshooting lab. Give a client a correct IP but bad DNS, then a working DNS setting but no DHCP lease. Compare `ipconfig`/equivalent output, ping behavior, name resolution, and APIPA. These contrasts are some of the most reusable support skills in Core 1.
Add a wireless interference exercise using a Wi-Fi analyzer. Observe nearby channels and signal strength, then compare 2.4 GHz and 5/6 GHz behavior if your hardware supports them. The goal is to see how radio environment affects connectivity even when passwords and IP settings are correct.
Add a cloud file-synchronization exercise. Sync a harmless test file through a consumer or lab cloud service, then test what happens offline and after reconnection. This gives practical context to cloud availability, synchronization, shared resources, and network dependency.
Add a printer queue lab where the physical printer is powered off or disconnected while jobs are submitted. Observe queue state, then restore connectivity. Compare that with a mechanical jam if you can simulate one safely. Software queue and physical printer failures produce different evidence.
Add a mobile MDM tabletop. Define one corporate-owned device and one BYOD device, then list which settings, applications, or restrictions the organization might enforce. This makes the mobile-management objective more realistic than memorizing the acronym alone.
Add a blind component-identification drill. Use photographs or spare hardware and identify ports, connectors, RAM, storage, expansion cards, CPU cooling, and printer parts without labels. Time yourself only after accuracy is reliable. Fast visual recognition can preserve exam time for harder scenario reasoning.
Finish every task by documenting symptom, evidence, action, and verification. CompTIA’s formal troubleshooting methodology is not itself an exam objective in V15, but structured support practice is exactly what the troubleshooting-heavy blueprint is trying to validate in context.
Add a BIOS/UEFI settings lab using a disposable or spare system. Find boot order, TPM, Secure Boot, virtualization support, fan/temperature monitoring, and firmware passwords. Record the current values before changing anything and restore them afterward. Firmware literacy can resolve problems before parts are swapped.
Add a RAM exercise by identifying DIMM versus SODIMM, channel placement, speed/generation labels, and ECC versus non-ECC concepts. If you have a spare desktop, inspect the motherboard manual to determine recommended slot order for dual-channel operation.
Add a RAID tabletop if you lack multiple drives. Draw RAID 0, 1, 5, 6, and 10 with a small number of disks and state usable-capacity pattern, redundancy, and failure tolerance conceptually. Then pair each with a troubleshooting symptom such as degraded array or missing disk.
Add a PoE lab with an access point, VoIP phone, or small PoE device if available. Check whether the switch/injector supplies appropriate power and observe link state. Compare a no-power condition with a powered device that simply lacks network connectivity.
Add a network-services lab using local or simulated DNS/DHCP. Create a reservation, change the DNS server, and inspect the lease. If a full server is unavailable, use the SOHO router’s interface and client commands to observe the same concepts.
Add one port/protocol validation exercise by connecting to safe local services and observing which transport port is used. The purpose is not network scanning; it is associating service purpose with the ports in the official objective list.
Add a mobile accessory compatibility lab. Test USB-C charging/data/video where supported, Bluetooth audio, NFC or hotspot behavior, and a dock or adapter. Record which features depend on hardware capability versus software configuration.
Add a VDI or remote-desktop comparison on paper if you do not have infrastructure. Contrast running an application locally, inside a local VM, through remote desktop, and through a virtual desktop environment. Identify where compute, storage, and troubleshooting responsibility move in each model.
Add one end-user communication step to blind tickets. Before touching the system, restate the problem in simple language, clarify what changed, and confirm the user’s priority. After the fix, explain what was changed and any preventive advice without unnecessary jargon. Support skill includes communication even when Core 1 focuses heavily on technical tasks.
Keep the lab safe and reversible. Use disposable VMs, spare components, and test networks for failures. Never risk important data merely to reproduce a drive, RAID, firmware, or network fault. Good hands-on preparation models the same caution expected from a real support technician.
Add a UPS/surge-protection check. Identify what should be connected to surge-only versus battery-backed outlets and what happens when utility power drops. This gives practical context to power protection without opening dangerous mains-powered equipment.
Add one projector/display support ticket: wrong input, fuzzy image, incorrect resolution, missing audio, or intermittent shutdown. Use source settings, cable/adapter, projector state, and thermal/physical evidence to isolate the fault. This covers a part of Domain 5 that is easy to neglect when most lab time goes to PCs and networks.
The 220-1201 generation is designed around this kind of support reasoning. A lab is successful when you can move from a vague complaint to the correct layer without randomly swapping parts.