20 free questions Original scenarios No account required

Free CompTIA A+ Core 1 practice test

Use an independently authored diagnostic to test the hardware, networking, mobile-device, virtualization, cloud, and troubleshooting reasoning expected in current A+ Core 1 preparation.

This is an independent study resource. It does not contain recalled, leaked, copied, or live-exam questions, and it is not affiliated with or endorsed by CompTIA.

Start the free practice test Open the full Core 1 study guide Core 2 practice test
Current reviewed track

Use the registry for changing exam facts.

Exam identity, timing, scoring, domain weighting, recommended experience, and review dates are rendered from Zeph Tech's maintained certification registry. That keeps volatile owner-published details separate from the durable troubleshooting material on this page.

Active

  • Exam: 220-1201
  • Version: V15
  • Questions: Maximum of 90 questions
  • Item types: multiple-choice, performance-based
  • Time: 90 minutes
  • Passing score: 675 on a 100–900 scale
  • Recommended background: 12 months of hands-on experience in an IT support specialist job role
  • Renewal: Three-year CompTIA Continuing Education cycle

Last verified: 2026-09-25

Next review: 2026-10-25

Official certification page · Official exam objectives

Published domain weighting

  • Mobile Devices13%
  • Networking23%
  • Hardware25%
  • Virtualization and Cloud Computing11%
  • Hardware and Network Troubleshooting28%
Diagnostic method

Use the test to find decision gaps, not to chase a percentage.

A+ questions become easier when you can move from a symptom to a likely layer, choose a safe first test, interpret the evidence, and verify the repair. That reasoning is more durable than memorizing a choice from one practice item.

Take the first pass without notes

Answer the twenty questions in one sitting if possible. Read the whole scenario before looking for a familiar keyword. Several answers may describe real technologies, but only one may address the symptom, scope, compatibility constraint, or next troubleshooting step in the question.

Mark any answer that felt like a guess even when it turns out to be correct. A lucky correct response is not the same thing as a concept you can retrieve under pressure or apply to a different workstation.

Write down the evidence you used

For hardware questions, note what observation narrows the fault domain. For network questions, note whether you are proving link, addressing, gateway reachability, name resolution, or application access. For mobile and cloud questions, identify the responsibility or compatibility boundary that makes one option stronger.

This forces you to practice the technician's actual job: using evidence to reduce uncertainty while avoiding unnecessary changes.

Separate knowledge misses from sequence misses

If you did not know what a technology does, that is a knowledge gap. If you knew the technology but chose a disruptive fix before a basic verification step, that is a troubleshooting-sequence gap. The remedies are different: one needs study; the other needs repeated decision practice.

Use domain feedback to route your review

The quiz engine groups misses by domain and links back into relevant Zeph Tech material. Use the weakest one or two domains to plan the next study session instead of rereading the entire certification guide from the beginning.

A+ Core 1 diagnostic

Twenty independently authored practice questions.

The set covers all five current Core 1 domains and includes explanations plus source links. Progress is stored locally in your browser; no registration or email address is required.

Loading the interactive practice test. If it does not load, ensure JavaScript is enabled.

Hardware and mobile review

Connect every component to compatibility, symptoms, and a safe test.

Hardware memorization becomes much more useful when each part is tied to three questions: what function does it provide, what must it be compatible with, and how would a failure present itself? A storage device, memory module, charger, display assembly, cooling system, power supply, printer component, or motherboard interface is easier to remember when you can place it inside a troubleshooting story.

For laptops and mobile devices, pay special attention to integrated components and power. A connector that physically fits does not guarantee the charger supports the required power profile. A dark internal display with working external video suggests a different path than a system with no video anywhere. A battery problem, damaged port, failed cable, firmware setting, or management restriction can all create symptoms a user describes simply as “it will not charge.”

When studying storage, distinguish interface, protocol, form factor, performance, power, capacity, and boot behavior. An M.2 slot may support different device types depending on the motherboard. A drive visible in firmware but not bootable suggests a different investigation than a drive that is not detected at all. Preserve data whenever possible before using repair actions that modify partitions or file systems.

For memory and processors, use motherboard documentation as the authority for slot population, supported generations, firmware requirements, cooling, and channel layout. Many real support mistakes happen because a technician recognizes the component category but skips the exact compatibility requirement.

Networking review

Build a short chain of proof from cable to application.

When a user says “the internet is down,” avoid treating that sentence as a diagnosis. Start with scope. Is one device affected or many? Does the interface have link? Did the system receive a plausible address? Can it reach the local gateway? Can it reach a remote IP address? Can it resolve a hostname? Can the intended application complete its own connection?

That sequence helps distinguish physical faults, DHCP problems, local addressing mistakes, routing failures, DNS problems, wireless interference, security-policy blocks, and application-specific failures. The exact tools vary by operating system, but the reasoning remains stable.

For small-office networks, understand logical roles even when one appliance performs several of them. A router, switch, access point, firewall, DHCP service, DNS resolver, modem or provider handoff, and NAT function solve different problems. If you can describe the path a packet should take and where addressing or translation occurs, troubleshooting becomes much less dependent on memorized product screens.

Wireless deserves its own evidence model. Signal strength is only one variable. Channel use, interference, airtime contention, client density, frequency band, authentication, roaming, access-point placement, and upstream capacity can all affect service. A strong signal with poor performance in a crowded room should not automatically lead to replacing the laptop radio.

Virtualization and cloud review

Identify who owns each layer and where the resource limit lives.

Virtualization questions often become simple after you separate guest, hypervisor, host, and upstream infrastructure. A guest operating system can be configured correctly yet perform badly because the host is oversubscribed. A snapshot can preserve a point in time without replacing a tested backup. A virtual network can be isolated or misconfigured independently of the physical interface used by the host.

For cloud service models, focus on responsibility rather than acronyms alone. Ask who manages the application, runtime, operating system, virtualization platform, and physical infrastructure. Then ask what the customer still controls: identity, data, configuration, endpoint access, and usage policies usually remain important even when much of the technology stack is provider-managed.

Use these boundaries during practice. If the provider operates the application itself and the customer primarily configures users and settings, that is a different responsibility model from a customer-managed virtual machine. If a virtual desktop cannot connect, identify whether the evidence belongs to the endpoint, identity provider, network path, cloud service, or the virtual guest before choosing a fix.

Troubleshooting review

Prefer the next action that creates evidence with the least risk.

A repeatable troubleshooting method begins with a precise problem statement. Gather the user's observation, recent changes, scope, environmental conditions, and any error messages. Reproduce the issue when safe. Check simple physical causes before assuming a complex failure, but do not stop at a superficial fix if the evidence suggests a deeper recurring condition.

Then establish a probable cause and choose a test that can meaningfully support or reject it. Changing several things at once may restore service but makes it harder to know which action mattered. It can also create new faults. One controlled variable at a time is usually the stronger diagnostic approach.

After implementing a fix, verify the original workflow rather than only checking the component you changed. A link light can be green while the application still fails. A drive can be visible while the system still does not boot. A printer can be online while the user still cannot send a job. Verification should match the original impact.

Finally, document the symptom, evidence, confirmed cause when known, action taken, result, and any follow-up. This habit improves exam reasoning because it forces you to distinguish a guess from a validated diagnosis, and it improves real support because another technician can understand exactly what happened.

After the score

Convert the result into a narrow study plan.

If hardware is weak

Build a compatibility table for storage, memory, interfaces, power, cooling, displays, printers, and common peripheral roles. For every item, add one failure symptom and one safe confirming test. That turns specification review into practical support knowledge.

If networking is weak

Practice the same diagnostic chain repeatedly: physical link, address, gateway, remote IP, DNS, and application. Draw a small home or lab network and label the DHCP, DNS, switching, routing, wireless, firewall, and NAT roles.

If mobile or cloud is weak

Focus on responsibility and compatibility boundaries. Compare charging standards, radios, synchronization, managed profiles, virtualization layers, and cloud service models. Ask who owns the failing component before choosing a support action.

If troubleshooting is weak

Take each missed question and write the smallest next test that would produce useful evidence. Practice resisting the urge to jump directly to reinstalling, replacing, resetting, or rebooting when a safer observation can narrow the cause first.

Continue the A+ path

Use the full study guide for the gaps this test exposes.

The A+ Core 1 study guide expands the same domains into hardware, endpoint networking, wireless, mobile devices, virtualization, cloud responsibility, troubleshooting methodology, and hands-on lab ideas. After Core 1, continue into Core 2 for operating systems, endpoint security, software troubleshooting, and operational procedures.

Open the Core 1 study guide Take the Core 2 practice test Build deeper networking skills
FAQ

A+ Core 1 practice-test questions.

Is this an official CompTIA practice exam?

No. Zeph Tech independently authors the material from public certification objectives and technical standards. CompTIA remains the authority for the certification, exam policies, objectives, pricing, scheduling, and current exam facts.

Are these real or recalled A+ questions?

No. The questions are original study scenarios. This site does not publish live-exam items, recalled questions, leaks, braindumps, or copied commercial test banks.

Does a high score mean I will pass?

No. This diagnostic is not a validated prediction of exam outcome. Use the score to identify weak domains, then check the certification owner's current objectives and practice those skills with new scenarios and hands-on work.

Do I need an account?

No. The interactive engine keeps progress in local browser storage and does not require registration. If you clear browser storage or switch devices, that local progress may not follow you.