RoleMath Study Track · free study companion

RoleMath Study Track for CompTIA Tech+ (FC0-U71)

A free study companion keyed to the officially published exam domains of CompTIA Tech+ (FC0-U71): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. CompTIA Tech+ (FC0-U71) certification page

A free, source-cited study companion built on CompTIA's published Tech+ (FC0-U71) objectives — not official training, not a pass guarantee. Verify the current objectives on the official CompTIA Tech+ page before your exam.

Program blueprint under review

Use the whole program, with the limits visible

A complete free CompTIA Tech+ program pinned to the current FC0-U71 scope, turning broad technology concepts into safe beginner artifacts across devices, infrastructure, software, development, data, and security without equating literacy with exam or job outcomes.

This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.

Modules
6
Labs
6
Concept checks
12
Resource mix
2 official / 0 community

Choose an outcome

Three routes through the same evidence

Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.

Certification-focused

Absolute beginners who have selected Tech+ and want one complete sequence across all six current FC0-U71 domains.

Completion emphasis: Complete every module and lab, the official sample set, the integrated small-solution capstone, and a final domain-by-domain gap review.

Required phases: Scope, tools, safety, and goal, Technology vocabulary and information flow, Devices, networks, accounts, and protection, Software models and logical instructions, Structured data and simple queries, Small digital solution and career-fit capstone

Technology skills first

Learners who want a reviewable sample of device, network, application, logic, data, and security reasoning before choosing a more specialized route.

Completion emphasis: Retain a device map, network observation, application comparison, pseudocode, structured data table, security checklist, test record, and plain-language handoff.

Required phases: Scope, tools, safety, and goal, Technology vocabulary and information flow, Devices, networks, accounts, and protection, Software models and logical instructions, Structured data and simple queries, Small digital solution and career-fit capstone

Career-fit sampler

People deciding whether technology work interests them and which of support, infrastructure, software, data, or security deserves deeper exploration.

Completion emphasis: Complete one representative artifact from every domain, score interest and frustration honestly, and use the capstone reflection to choose a next experiment rather than assume Tech+ itself proves job readiness.

Required phases: Scope, tools, safety, and goal, Technology vocabulary and information flow, Devices, networks, accounts, and protection, Software models and logical instructions, Structured data and simple queries, Small digital solution and career-fit capstone

Start safely

Prerequisite diagnostic

Choose owned, accessible, low-risk tools and a learning goal before the beginner labs; this diagnostic is not a prerequisite, intelligence test, or exam prediction.

  1. Do you have a phone, tablet, or computer you own and may inspect without opening hardware or changing managed settings?

    Ready when: Yes, for read-only settings and observations, or you can use the written fictional-device alternative.

    If not yet: Use the provided concepts and fictional specification route; never inspect, install on, or alter someone else's or a work-managed device.

  2. Can you open settings, a browser, a text editor, a spreadsheet, and a terminal with written steps?

    Ready when: Yes, even if each tool is new and the command line requires a guided warm-up.

    If not yet: Start with the interface-navigation warm-up and use screenshots or command transcripts until opening and closing each tool is comfortable.

  3. Can you use only a personal account you control for optional MFA or cloud-sync practice and store recovery codes safely?

    Ready when: Yes, without using work, school, shared, or another person's account.

    If not yet: Use the written MFA decision and recovery checklist; do not create or change an account solely to complete the lab.

  4. Can you create fake names, dates, device labels, and records rather than using real personal, employer, client, or confidential information?

    Ready when: Yes, with a rule that every capstone record is invented.

    If not yet: Use the supplied fictional organization and generic sample labels; do not copy contacts, messages, files, or account details into artifacts.

  5. Do visual, motor, device, account, connectivity, or software constraints require a transcript, paper, or observation-only alternative for any lab?

    Ready when: Either live or alternative evidence is acceptable when it is labeled honestly and preserves the learning objective.

    If not yet: Choose the written, paper, screenshot-description, or expected-output route before the module and record what was observed rather than executed.

  6. Are you pursuing FC0-U71, broad technology confidence, or a structured career-fit experiment?

    Ready when: One provisional goal is selected and may change when the artifacts reveal a better next direction.

    If not yet: Start with the career-fit sampler and defer exam spending until the six domain experiences support a decision.

Plan, then adapt

Pace options

Steady

8 weeks 4-6 hours/week

A planning estimate for absolute beginners: give each domain its own low-pressure week and reserve the final weeks for the integrated solution and next-direction reflection.

Standard

6 weeks 6-8 hours/week

A planning estimate that pairs related domains while keeping separate practice time for unfamiliar tools, accessibility alternatives, and the capstone.

Intensive

3 weeks 10-14 hours/week

For learners already comfortable with everyday devices and applications; slow down when terminology, logic, data structure, or security reasoning cannot be explained without copying the steps.

Evidence-gated sequence

Program roadmap

  1. Scope, tools, safety, and goal

    Pin FC0-U71, choose certification or exploration intent, select owned and accessible tools, and establish fictional-data and account-safety rules.

    Exit evidence

    • Confirm the current FC0-U71 domains and weights on CompTIA's official page.
    • Choose a provisional goal and pace plus live or alternative route for each required tool.
    • Create a project folder and commit to owned devices, personal accounts, fictional data, and no sensitive screenshots.
  2. Technology vocabulary and information flow

    Make bits, bytes, units, notation, value types, and the input-process-output-storage model concrete before using them in later domains.

    Exit evidence

    • Produce an input, processing, output, and storage map for an owned or fictional device.
    • Explain processor, memory, storage, data, information, units, and common notation in beginner language.
    • Correct every missed concepts check against its cited source and write one new everyday-device example.
  3. Devices, networks, accounts, and protection

    Observe how a device connects and how identities, confidentiality, integrity, availability, updates, backup, and safe behavior protect it.

    Exit evidence

    • Retain an authorized local-network observation or transcript covering address, gateway, DNS, reachability, and path.
    • Enable MFA on a personal account or complete the written factor/recovery/lockout alternative without exposing account details.
    • Produce a CIA, account, update, backup, phishing, physical, and privacy checklist with at least one safe improvement or explicit gap.
  4. Software models and logical instructions

    Compare local, web, and cloud-synced applications and express a small process through sequence, selection, iteration, variables, testing, and debugging.

    Exit evidence

    • Produce a local/web/cloud application comparison covering execution, connectivity, updates, data location, access, and tradeoffs.
    • Write and hand-run pseudocode containing a sequence, decision, loop, variable, valid case, and error or edge case.
    • Explain the difference among an operating system, application, browser app, service, algorithm, program, and programming language.
  5. Structured data and simple queries

    Turn fictional facts into a consistent table with fields, records, types, keys, relationships, sorting, filtering, quality checks, privacy, and backup decisions.

    Exit evidence

    • Retain a fictional table with fields, records, types, unique primary keys, a duplicate-name test, sorting, filtering, and one validation rule.
    • Explain why a key identifies a record and how a related second table reduces repetition.
    • Record one integrity, privacy, retention, access, and backup control for the fictional data.
  6. Small digital solution and career-fit capstone

    Integrate all six domains into a simple fictional solution, test it, document its controls and limitations, and use the experience to choose a better-informed next technology direction.

    Exit evidence

    • Complete the capstone and pass its fictional-data, logic, consistency, security, usability, backup, and privacy review.
    • Crosswalk all six domains to at least one artifact and one corrected or confidently explained check.
    • Record interest, frustration, confidence, remaining gaps, and a specific next experiment without treating completion as job readiness.

Before a lab

Environment, access, and safety

Required and optional setup

Required

  • A phone, tablet, computer, or written fictional-device alternative plus a browser, text editor, and notes or paper
  • A local or free web spreadsheet, or a paper table alternative, for fictional structured data
  • A dedicated folder for device maps, network observations, comparisons, pseudocode, data tables, security checklists, tests, and reflections

Optional

  • A personally controlled online account for optional MFA and cloud-sync observation
  • A second personally owned device for sync comparison
  • Free diagramming software and a local spreadsheet such as LibreOffice for no-account work
Accounts and accessibility routes

Accounts

  • No account is required for the core concepts, infrastructure, pseudocode, local-application, data, or written-security routes.
  • MFA and cloud-sync practice may use an existing personal account only; a work, school, shared, or newly purchased account is not required.
  • Web spreadsheets are optional because a local spreadsheet or paper table provides a no-account alternative.

Equivalent routes

  • Use a fictional device specification, command transcript, screenshot description, paper flowchart, or printed table when hardware, motor, visual, connectivity, account, or software constraints block a step.
  • Label artifacts as executed, observed, simulated, or planned so the evidence never implies an interaction that did not occur.
  • Split setup, observation, authoring, testing, and reflection across sessions without reducing safety, privacy, or module exit criteria.
Safety baseline
  • Inspect only owned devices and personal accounts; do not open hardware, alter managed settings, install untrusted software, scan networks, or use work, school, shared, or another person's systems.
  • Use invented data throughout, remove account and device identifiers from evidence, store recovery codes privately, and never publish credentials, QR codes, sessions, contact lists, or network details.
  • When viewing spam, read only without clicking, downloading, replying, forwarding, or enabling content; report employer-targeted content through the employer's process.
  • Prefer read-only observation and document changes, recovery, backup, and rollback before any optional personal-account setting change.

Show your work

Module evidence and missed-check protocol

Module exit evidence

  • A saved device map, network observation, app comparison, pseudocode, data table, security checklist, or clearly labeled accessibility alternative tied to the domain map.
  • A beginner-readable explanation of what the artifact represents, what was observed or tested, what was not done, and why it matters.
  • All authored checks attempted, with each miss corrected against its cited source and applied to a new everyday technology example.

After a missed check

  1. Identify whether the question tests concepts, infrastructure, software, logic, data, or security before reviewing the answer.
  2. Write why the distractor was plausible and which device role, network fact, application property, logic path, table rule, or security objective distinguishes it.
  3. Create and answer a simpler example in plain language, then a second example from a different device or context.

Completing this policy demonstrates FC0-U71 coverage and broad technology practice inside RoleMath; it does not predict an exam score, establish job readiness, or replace deeper role-specific training.

Integrated practice

Fictional community-club equipment and event tracker

Design, build, test, secure, and explain a small fictional tracking solution that samples device, infrastructure, application, development, data, and security work and produces an evidence-based next-direction reflection.

Workflow

  1. Write a fictional brief for a community club that needs to track invented equipment, member aliases, checkout and return dates, event assignments, item condition, and follow-up without using real people or contact information.
  2. List users, tasks, inputs, processing decisions, outputs, storage, availability needs, privacy limits, and out-of-scope features. Mark each element on an input-process-output-storage diagram.
  3. Create a device and infrastructure map showing one user device, local network/gateway, internet boundary, application location, data location, backup location, and who is responsible for each part. Use fictional labels and no real network identifiers.
  4. Compare local spreadsheet, browser-based spreadsheet, and a hypothetical dedicated application for the tracker. Score offline use, collaboration, updates, data location, access, backup, cost, complexity, and privacy; choose one and state what would change the decision.
  5. Build the tracker in a local or free spreadsheet using invented records. Include unique item and transaction keys, field types, validation, sorting, filtering, status, and a relationship or lookup between equipment and checkout records.
  6. Write pseudocode for checkout and return: validate the item and member alias, check availability, record the transaction, update status, repeat for multiple items, handle missing or duplicate data, and produce a confirmation or error.
  7. Hand-run the pseudocode against at least five tests: normal checkout, unavailable item, invalid identifier, duplicate transaction, and return with a condition note. Record expected and actual outcomes and revise the logic or table when they disagree.
  8. Create a security and resilience checklist using confidentiality, integrity, and availability: least access, MFA for any optional online account, fictional data, validation, update responsibility, backup, restore test, recovery codes, phishing awareness, physical safety, retention, and deletion.
  9. Create three tabletop problems: the device is lost, a record is changed incorrectly, and internet access is unavailable. For each, identify impact, evidence, safe response, recovery, communication, and the control that would reduce recurrence.
  10. Write a one-page beginner user guide showing how to add an item, check it out, return it, filter open transactions, correct an error safely, back up the file, and request help without exposing data.
  11. Review the solution for internal consistency: keys are unique, statuses match transactions, pseudocode matches fields, test results match logic, access and backup fit the chosen application model, and no real data or account detail appears.
  12. Create a six-domain crosswalk linking each artifact to Tech+ objectives and mark uncovered topics as gaps.
  13. Complete a career-fit matrix for support/hardware, infrastructure/networking, software/application work, development logic, data work, and security. Record interest, frustration, evidence, and one low-cost next experiment for each, then choose the next experiment without calling it a career guarantee.

Retained artifacts

  • Fictional requirements plus input-process-output-storage and infrastructure maps
  • Local/web/cloud application comparison and selection record
  • Structured equipment and transaction tables with validation and queries
  • Checkout/return pseudocode and five-case test record
  • CIA/security/resilience checklist and three tabletop response records
  • Beginner user guide and consistency review
  • Six-domain crosswalk, career-fit matrix, and next-experiment decision

Review checklist

  • Requirements, maps, application choice, fields, keys, records, pseudocode, tests, controls, incidents, and user guide describe the same fictional solution without contradictions.
  • All names, dates, devices, networks, events, accounts, and records are invented, with no real personal, employer, client, contact, credential, or network data.
  • The solution handles normal, invalid, duplicate, unavailable, offline, lost-device, incorrect-data, backup, restore, and help/escalation conditions in beginner-readable language.
  • Security controls match actual risks and include access, MFA where applicable, validation, updates, backup/restore, recovery, privacy, retention, deletion, and safe user behavior.
  • Every live step used owned tools and accounts; observation-only alternatives are labeled and do not imply execution.
  • All six FC0-U71 domains map to at least one artifact; uncovered topics remain explicit gaps rather than implied completion.
  • The packet does not claim exam success, official CompTIA training, job readiness, professional experience, or a RoleMath credential.

Safety boundary: Use only owned devices, optional personal accounts, trusted software, and invented data. Do not open hardware, alter managed systems, expose recovery codes or credentials, use real contacts or identifiers, interact with suspicious content, or test networks you do not own. Observation-only work must be labeled honestly.

Finish honestly

Completion, portfolio, and maintenance

Completion evidence

  • All six current FC0-U71 domain modules have been covered and checked against CompTIA's official page.
  • Every domain lab has a saved owned-device artifact, fictional exercise, or clearly labeled accessibility alternative.
  • Every authored knowledge check has been attempted and each miss has a cited correction plus a fresh everyday example.
  • The official CompTIA sample set has been used to calibrate scope and wording rather than memorized as an answer bank.
  • The community-club capstone passes concepts, infrastructure, application, logic, data, security, testing, privacy, accessibility, consistency, and six-domain coverage review.
  • The learner has recorded remaining gaps and a specific next experiment; completion is not represented as an exam result, credential, job readiness, or professional experience.

Portfolio candidates

  • A sanitized small-solution requirements and architecture map
  • A fictional structured data table and query examples
  • Pseudocode plus normal and edge-case tests
  • A security/resilience checklist and tabletop recovery record
  • A beginner user guide
  • A six-domain career-fit matrix and next-experiment reflection

Present the artifacts as self-directed Tech+ learning and career-fit exploration. Do not call them professional technology experience, a production application, official CompTIA training, job readiness, or a RoleMath credential.

Freshness controls

Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 90 days.

Stop and re-verify when

  • CompTIA changes the active Tech+ exam code, V6/FC0-U71 scope, domain, published weight, lifecycle, or official no-prerequisite guidance.
  • An official objective, sample, application, account, MFA, spreadsheet, command, browser, or other referenced resource changes ownership, URL, free-access posture, behavior, or safety.
  • A lab or capstone step can no longer be completed with owned/free tools, fictional data, an accessible route, and the stated privacy and recovery safeguards.
  • An account, operating system, application, command, spreadsheet, or authenticator workflow materially differs from the documented instructions.
  • Any module, lab, check, resource mapping, phase, or capstone fails technical, source, beginner-walkthrough, safety, privacy, accessibility, job-readiness, or claims review.

Skills measured

The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. CompTIA Tech+ (FC0-U71) certification page

24%InfrastructureCompTIA Tech+ (FC0-U71) certification page (2026-06-12)
19%SecurityCompTIA Tech+ (FC0-U71) certification page (2026-06-12)
18%Applications and softwareCompTIA Tech+ (FC0-U71) certification page (2026-06-12)
13%Tech concepts and terminologyCompTIA Tech+ (FC0-U71) certification page (2026-06-12)
13%Software development conceptsCompTIA Tech+ (FC0-U71) certification page (2026-06-12)
13%Data and database fundamentalsCompTIA Tech+ (FC0-U71) certification page (2026-06-12)

Suggested study order

Our default advice is to study the heaviest-weighted domain first, because the published weights tell you where the exam spends its questions — which, for Tech+, means Infrastructure (24%), then Security (19%), then Applications and software (18%), then the three 13% domains. Tech+ gets one honest exception at the very front. Domain 1, Tech concepts and terminology, carries only 13%, but it is the vocabulary — bits and bytes, input/processing/output/storage, units and notation — that every other domain quietly assumes you already speak. Reading about infrastructure or databases before you can say what a byte or a process is makes all of them harder. So we suggest: start with Tech concepts and terminology as your foundation, then follow the weights — Infrastructure (24%), Security (19%), Applications and software (18%), Software development concepts (13%), and Data and database fundamentals (13%). This is sequencing advice based on the published weights and how the topics depend on each other, not a claim about the science of learning — if a different order fits how you think, use it.

  1. Tech concepts and terminology13% of the exam
  2. Infrastructure24% of the exam
  3. Security19% of the exam
  4. Applications and software18% of the exam
  5. Software development concepts13% of the exam
  6. Data and database fundamentals13% of the exam

Module 1 of 6 · domain 1 · 13% of the exam

Tech concepts and terminology

Start here even though two other domains weigh more. This domain defines the base vocabulary — how computers represent information, the input-process-output-storage cycle, and the units and notation everything else uses — that the infrastructure, software, data, and security domains all assume you already speak.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'what are we even talking about' domain — the shared language of computing, taught from zero. Before Tech+ asks you about hardware, apps, data, or security, it makes sure you can name the basic ideas those topics are built on: how a computer represents information, the cycle every computing device runs, and the units and notation you will see everywhere else. It carries 13% of the scored content, which sounds small, but its real weight is that the other five domains are written in the words this one teaches. If a later topic ever feels like a foreign language, the gap is almost always somewhere in here.

The most foundational idea is that computers represent everything — text, pictures, sound, video — as numbers, and ultimately as bits, the on/off ones and zeros that hardware can physically store. Eight bits make a byte, and bytes are the unit files and memory are measured in, scaling up through kilobytes, megabytes, gigabytes, and terabytes. It is worth getting comfortable with the fact that a single character of text, a whole song, and a high-resolution photo differ enormously in how many bytes they take, because that intuition quietly explains storage sizes, download times, and why some files are 'heavy.' You are not doing binary math on the exam so much as recognizing that underneath everything friendly on your screen sits numbers.

The next idea is the notational and data-type vocabulary: the difference between decimal (the base-10 numbers people use), binary (base-2, how the machine thinks), and hexadecimal (base-16, a compact shorthand you meet in color codes and addresses); and the basic kinds of values software works with — whole numbers, decimal numbers, true/false values, single characters, and strings of text. You do not need to convert between number bases fluently, but you should recognize what each notation is for and why a program cares whether a value is a number, a word, or a yes/no. These distinctions come back directly in the software-development and data domains.

The domain also frames the computing process itself: the input-process-output cycle, plus storage. Every computing device takes input (a keystroke, a tap, a sensor reading), processes it (the work the processor does), produces output (something on a screen, a sound, a saved result), and can store information for later. Recognizing those four roles in any device — a phone, a thermostat, a car's dashboard — is a small skill with big payoff, because the whole rest of the certification is really about the pieces that perform each of those roles and how they connect. The lab below has you spot all four on a device you own.

Finally, this domain covers units and measures beyond storage — the numbers that describe how fast and how much: processor speed, memory size, network throughput, screen resolution, and the difference between the bits used to measure network speed and the bytes used to measure storage (a distinction that trips up beginners and explains why a fast connection still takes time to move a big file). It also introduces the everyday troubleshooting mindset the exam values throughout: approaching a problem methodically — identify what is wrong, consider likely causes, test a fix, and confirm it worked — rather than randomly poking at settings. That calm, stepwise habit is worth more than any single fact.

On the job, this domain is the difference between memorizing tech words and actually understanding them. A good way to study is to stop reading and start naming: pick up any device around you and narrate its input, processing, output, and storage out loud; look at a file's size and translate it into 'that's about this many photos'; and explain to a friend, in plain words, why a computer stores everything as numbers. If you can do that without notes, you have what this domain checks for. Read the official CompTIA Tech+ objectives for the exact topic list — the wording there is CompTIA's own, and this explanation deliberately paraphrases rather than reproduces it.

Learn it free

Lab: find input, processing, output, and storage on a device you own

Turn the abstract input-process-output-storage cycle into something you can point at: take a device you already own — a laptop, phone, or tablet — and physically identify the parts that perform each of the four roles, then check its storage size and translate it into everyday terms. This is the core Domain 1 mental model, made concrete, using only a device you already have.

Free tools

  • A device you personally own — a laptop, desktop, phone, or tablet
  • That device's own built-in settings or 'About' screen (free, already installed) to read its specifications
  • Optional: a sheet of paper or a notes app to write down the four roles and what fills each

Steps

  1. Pick a device you own and sit with it. Write four headings on paper or in a notes app: Input, Processing, Output, Storage.
  2. Fill in Input: list every way information gets into this device from the outside — keyboard, touchscreen, mouse or trackpad, microphone, camera, fingerprint sensor. Each of these is an input device feeding the machine.
  3. Fill in Output: list every way the device shows or sends information back out — the screen, the speakers, a vibration, a headphone jack or Bluetooth audio. Each is an output.
  4. Fill in Processing: this is the part you cannot see — the processor (CPU) that does the actual work, helped by short-term memory (RAM) that holds what it is working on right now. You will confirm these on the About screen in the next step.
  5. Fill in Storage: the place information is kept even after the power is off — the internal drive, plus any memory card or cloud storage the device uses. This is different from RAM, which forgets everything when the device powers down.
  6. Open the device's About or specifications screen. On Windows: Settings → System → About. On a Mac: Apple menu → About This Mac. On a phone: Settings → About phone/device. Read the processor name, the amount of memory (RAM), and the storage capacity.
  7. Translate the storage number into everyday terms. If the device has, say, 128 gigabytes of storage, note that a typical phone photo is a few megabytes and a full-length song a few megabytes too — so 128 GB is roughly tens of thousands of photos. Seeing storage as 'how many things fit' is the byte-and-unit intuition this domain teaches.
  8. Compare RAM to storage on the About screen: notice the RAM number is much smaller than the storage number. Reflect on why — RAM is the fast workspace the processor uses right now, storage is the larger long-term shelf. Mixing up the two is one of the most common beginner errors this domain wants you to avoid.
  9. Optional: repeat the four-role exercise on a completely different device — a smart TV, a game console, a car dashboard, a smart speaker. Confirming that the same input-process-output-storage cycle appears in devices that look nothing alike is the point: it is a universal pattern, not a computer-only one.

What you should see

A device broken into four labeled roles you can point at — the parts that take information in, the processor and memory that work on it, the parts that put results out, and the drive that keeps it — plus a real storage figure you have translated into 'about this many photos or songs.' You have seen the input-process-output-storage cycle and the byte-and-unit vocabulary as concrete facts about a device in your hands, not as definitions on a page.

This lab practices the core computing-concepts vocabulary — the input/processing/output/storage cycle and units of storage — that Domain 1 (Tech concepts and terminology) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: Only inspect a device you personally own. This lab is read-and-observe: you are only reading an 'About' screen and looking at the hardware, not changing any setting, installing anything, or opening the device up. Never take apart or probe a device you do not own or that belongs to someone else.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. A small business uses web-based email where the vendor manages the application and infrastructure. Which technology concept best describes this?
Check 2. A browser requests a web page from a remote system that responds with content. Which basic model is being used?

Module 2 of 6 · domain 2 · 24% of the exam

Infrastructure

Second in our suggested order and the heaviest domain at 24%. Study it right after the vocabulary domain: once you can name inputs, outputs, and storage, infrastructure is the story of the actual physical parts that perform those roles and the networks that connect them.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'what are the actual parts, and how do they connect' domain, and at 24% it is the single heaviest slice of the Tech+ exam — so it deserves your largest block of study time. Where Domain 1 gave you the vocabulary, this domain populates the machine with real components: what is inside a computer, the devices you plug into it, how it gets onto a network and the internet, and the different kinds of computing (from a phone in your pocket to servers in a data center). Nobody expects a Tech+ candidate to be a technician; the exam expects you to recognize the main parts and connections by purpose, which is exactly what makes it approachable.

Start inside the computer with the core internal components, learned by what each one does. The processor (CPU) is the brain that carries out instructions. Memory (RAM) is the fast, temporary workspace it uses for whatever it is doing right now — and which forgets everything when the power goes off. Storage — a solid-state drive or hard disk — is the long-term shelf that keeps your files and programs even when the device is off. The motherboard is the board everything plugs into and communicates through, and the power supply feeds it electricity. The exam's recurring skill is matching a described symptom or need to the right part — 'the machine is slow when many programs are open' points toward memory, 'it is running out of room for files' points toward storage.

Around the core sit peripherals and ports — the devices you connect and the sockets you connect them through. Input peripherals (keyboard, mouse, webcam, scanner) and output peripherals (monitor, printer, speakers) attach through connection standards you should be able to recognize by name and rough purpose: the general-purpose USB family for most devices, video connectors like HDMI for displays, and wireless connections like Bluetooth for nearby accessories. You are not memorizing pin counts; you are learning that a given job — connect a monitor, connect a phone, connect a wireless headset — has a typical connector, so a described need points to a recognizable answer.

The largest and most modern part of the domain is networking — how a device reaches other devices and the internet. A few ideas anchor it. Devices join a local network through wired connections (an Ethernet cable) or wireless ones (Wi-Fi), usually through a router that also connects the local network out to the internet through an internet service provider. Every device on a network has an address (an IP address) so traffic can find it, and human-friendly website names get translated into those addresses by a lookup system (DNS, the internet's phone book). The exam wants you to recognize these pieces and follow, at a high level, how your laptop's request for a web page travels out to the internet and back — which is precisely what the lab below has you trace on your own machine.

The domain also introduces the shapes computing comes in and where it runs. On one end are the devices you hold and use directly — laptops, desktops, phones, tablets, and the growing world of internet-connected 'smart' devices. On the other end are servers and the cloud: powerful shared computers, often in distant data centers, that store data and run services you reach over the internet rather than owning yourself. Virtualization — running a 'computer inside a computer' as software — and the basic idea of cloud computing (renting computing over the internet instead of buying and housing it) round this out. You are being asked to tell these categories apart and recognize when each fits, not to build any of them.

Study this domain by grounding every component in your own equipment: open your computer's specifications and match what you read to the parts above; look at the cables and ports on your devices and name each connector's job; and trace your own internet connection from laptop to router to the wider internet. The lab below has you inspect your machine's own network settings — its address, its router, and how it reaches the internet — turning the networking half of this domain from diagram into something you have read on your own screen. And read the official CompTIA Tech+ objectives for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.

Learn it free

Lab: inspect your own machine's network settings and trace its path to the internet

Turn abstract networking into concrete facts about your own device: use your computer's built-in commands to read its IP address, find the router it connects through, and confirm it can reach the internet — following, on your own machine, the path from laptop to router to the wider internet that this domain describes. No downloads, no cost.

Free tools

  • The computer you own, with its built-in command-line tool (Command Prompt or PowerShell on Windows; Terminal on macOS or Linux) — free and already installed
  • Your existing internet connection (Wi-Fi or Ethernet) — the same one you already use

Steps

  1. Open your command-line tool. Windows: press Start, type 'cmd', and open Command Prompt. macOS/Linux: open the Terminal app.
  2. Read your device's own network address. Windows: run ipconfig . macOS/Linux: run ip addr (or the older ifconfig , if your system still has it). Find the IPv4 address (something like 192.168.x.x) — that is your device's address on your local network, the way traffic finds it.
  3. Find your router — the device that connects your local network to the internet. Windows: in the ipconfig output, read the 'Default Gateway' address. macOS: run netstat -nr | grep default (or read System Settings → Network → Details). That gateway address is your router.
  4. Confirm you can reach the wider internet. Run ping comptia.org (or ping 8.8.8.8 ). Watch the replies come back with a time in milliseconds — each reply is your request reaching a distant server and returning. Press Ctrl+C to stop.
  5. See name-to-address translation (DNS) in action. Run nslookup comptia.org (works on Windows, macOS, and Linux). The tool returns one or more IP addresses — you have just watched a human-friendly website name get turned into the numeric address the network actually uses.
  6. Optional: trace the route your traffic takes. Windows: run tracert comptia.org . macOS/Linux: run traceroute comptia.org . Each line is a hop — a router your request passes through on its way across the internet. Seeing several hops makes 'the internet is a network of networks' concrete.
  7. Reflect on the path you just traced: your device (its IP address) → your router (the gateway) → your internet service provider → the wider internet → the destination server → and all the way back. That round trip is the networking story Domain 2 tells, now confirmed on your own connection.
  8. Optional: compare wired vs wireless if you can. If you are on Wi-Fi, note it; if you have an Ethernet cable, plug in and re-run ipconfig / ifconfig to see the connection change. Both get you to the same internet through the same router — different first hop, same journey.

What you should see

Your device's own IP address, the router (default gateway) it connects through, successful ping replies proving you can reach a distant server, and a DNS lookup turning a website name into a numeric address — optionally a multi-hop traceroute across the internet. You have seen the local-network-to-internet path, addressing, and name resolution as real output about your own connection rather than as a diagram.

This lab practices the networking and connectivity concepts — IP addressing, routers/gateways, DNS name resolution, and the local-network-to-internet path — that Domain 2 (Infrastructure) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: Only run these commands on a computer and network you personally own or are authorized to use, and only against public sites (like comptia.org) or your own devices. These commands are read-only and standard — ipconfig, ping, and nslookup simply report and check connectivity. Never point scanning or probing tools at networks, addresses, or devices you do not own.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. Users can reach a site by IP address but not by name. Which infrastructure service should be checked?
Check 2. A laptop drive fails and the user needs recent files restored. Which infrastructure practice matters most?

Module 3 of 6 · domain 6 · 19% of the exam

Security

Third in our suggested order, per its 19% weight — the second-heaviest domain. Study it after infrastructure: security in Tech+ is mostly about protecting the devices, accounts, and data you have just learned to recognize, so it reads more clearly once those pieces have names.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'how do you keep it all safe' domain, and at 19% it is the second-heaviest slice of the exam — for good reason, since security is the part of tech every worker and every career changer is now expected to understand. This domain covers what security is trying to protect, the everyday threats you and organizations face, and the practical habits and controls that reduce risk. The good news for a beginner is that most of it is common sense made systematic: strong passwords, being suspicious of scams, keeping software updated, and backing up your data. You already have some of these instincts; the exam gives them structure and names.

The idea everything hangs on is the same three goals security exists to protect, usually called the CIA triad. Confidentiality means only the right people can see something — your messages and files should not be readable by strangers. Integrity means information is not secretly altered — a bank balance should reflect only real transactions. Availability means systems and data work when you need them — a service should be up when you go to use it. Almost any safeguard you can name protects one or more of these three, and a surprising share of exam-style questions are really asking which goal a described situation puts at risk. Getting comfortable naming confidentiality, integrity, or availability from a plain story is one of the highest-value skills in this domain — and the lab below has you spot all three in your own habits.

Next come the threats — the ways things go wrong, which the exam expects you to recognize by description. Malware is malicious software in its various forms: viruses, ransomware that locks your files for payment, spyware that watches you, and more. Social engineering attacks target people rather than machines — phishing emails and messages that trick you into revealing a password or clicking something harmful are the classic example, and they succeed by manipulating trust and urgency. Other threats include weak or reused passwords, unsecured networks, physical theft of a device, and simple human error. The unifying insight the exam wants is that many attacks aim at the person, not the technology, which is why awareness and healthy suspicion are themselves security controls.

Against those threats sits the toolkit of protections, the practical heart of the domain. Authentication proves who you are, drawing on something you know (a password), something you have (a phone or security key), and something you are (a fingerprint or face); combining two kinds is multi-factor authentication, the single cheapest way to blunt stolen-password attacks. Strong, unique passwords — ideally managed with a password manager — protect accounts; encryption scrambles data so a thief gets only gibberish; keeping software updated closes the holes attackers exploit; backups protect availability by letting you recover after loss or ransomware; and firewalls and antivirus software filter and catch threats. The exam checks that you can match a described need — 'stop a stolen password from being enough,' 'recover after ransomware,' 'protect data on a lost laptop' — to the right protection.

The domain also covers the human, physical, and privacy layers that make the technical controls stick. Good security behavior — locking your screen, not sharing passwords, verifying suspicious requests, following the principle of using only the access you need — matters as much as any tool. Physical security (locking devices away, controlling who can reach equipment) protects against the low-tech theft that defeats fancy software. And privacy — handling personal information responsibly, understanding what data is collected about you, and knowing that laws govern its protection — is treated as a first-class concern, because so much of security exists to protect people's data and trust. Safe web browsing and email habits, and recognizing secure connections, live here too.

Study this domain by turning it on yourself: audit your own security habits against the concepts above. Do your important accounts have multi-factor authentication? Are your passwords strong and unique? Is your device encrypted and backed up? Would you recognize a phishing attempt? The lab below has you enable multi-factor authentication on a personal account and then map the CIA triad onto your own habits, so confidentiality, integrity, and availability stop being definitions and become a lens on your real digital life. As with every domain on this track, read the official CompTIA Tech+ objectives for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.

Learn it free

Lab: enable multi-factor authentication and map the CIA triad onto your own habits

Make security personal and concrete: turn on multi-factor authentication (MFA) on a personal account you own so a stolen password alone can no longer get in, then walk your own digital habits and name where confidentiality, integrity, and availability show up. You will experience the cheapest strong control in security and see the CIA triad as a lens on your real life — all free.

Free tools

  • A free personal online account you already own and control (for example your personal email) — never a work or employer account for this lab
  • A free authenticator app on a phone you own (for example Google Authenticator, Microsoft Authenticator, or any TOTP app) — free from your device's app store
  • Any modern web browser — free, already on your machine
  • Optional: paper or a notes app to write your CIA-triad audit

Steps

  1. Choose a personal account you own — your own email is ideal because it protects so many other accounts — and sign in on its website. Open Settings, then the Security or Sign-in section.
  2. Find the option named 'Two-step verification,' 'Two-factor authentication,' or 'Multi-factor authentication' and begin enabling it. Read what the provider says it protects against — it will describe stopping someone who has stolen your password.
  3. When offered a method, choose an authenticator app (a code that changes every 30 seconds) over text-message codes if the option exists, since the app method is generally sturdier. Install a free authenticator app on your phone if you do not have one.
  4. Scan the on-screen QR code with the authenticator app. The app now shows a six-digit code that changes on a timer — the 'something you have' factor joining your 'something you know' password.
  5. Enter the current six-digit code where the website asks, to confirm the pairing. Save the backup/recovery codes the provider offers somewhere safe — they are your way back in if you lose the phone.
  6. Sign out completely, then sign back in. Notice the new flow: your password alone is no longer enough — the site also asks for the changing code from your app. A thief with only your password now gets nowhere.
  7. Now do the CIA-triad audit. Write three headings — Confidentiality, Integrity, Availability — and under each, name something you already do (or should) that protects it. Confidentiality: MFA and strong passwords keep others out of your accounts. Integrity: not reusing passwords, and being suspicious of phishing, keeps attackers from altering your data or impersonating you. Availability: backing up your photos and files means a lost or ransomed device does not erase them.
  8. Fill any gaps you notice honestly: an account without MFA (confidentiality gap), passwords reused across sites (integrity/confidentiality gap), or important files with no backup (availability gap). Naming a gap is the first step to closing it — and it is exactly the risk-spotting this domain teaches.
  9. Optional: spot a threat in the wild safely. Look in your email's spam folder (do not click anything) and identify one phishing attempt — note the tricks it uses: false urgency, a slightly-wrong sender address, a link that does not match the real site. Recognizing social engineering is a core security skill.
  10. Optional: check one more protection habit — is your computer's disk encryption turned on (BitLocker on Windows, FileVault on Mac), and do you have a recent backup? Both protect data on a lost or failed device, tying the security domain back to real device safety.

What you should see

A personal account that now requires two kinds of proof to sign in — so a stolen password alone fails — and a written audit that maps confidentiality, integrity, and availability onto your own real habits, with any gaps named. You have experienced multi-factor authentication as the cheapest strong control and turned the CIA triad from three definitions into a working lens on your own digital security.

This lab practices the security fundamentals — the CIA triad, authentication and multi-factor authentication, recognizing threats like phishing, and protective habits such as backups and encryption — that Domain 6 (Security) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: Do this only on a personal account you own — never a work, school, or someone else's account, and never on a shared or public computer. Store your backup/recovery codes safely, since losing your second factor without them can lock you out. When inspecting spam for phishing, read only — do not click links, open attachments, or reply. Enabling MFA and reviewing your own habits touches no system you do not own.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. An account is protected only by a reused password. Which security control most directly reduces account-takeover risk?
Check 2. A message asks a user to enter credentials on a lookalike login page. What threat should be suspected?

Module 4 of 6 · domain 3 · 18% of the exam

Applications and software

Fourth in our suggested order, per its 18% weight. Study it after infrastructure and security: once you know the hardware and how to keep it safe, this domain is about the software that runs on top of it — operating systems, apps, and where they run.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'what runs on the machine, and where does it run' domain, and at 18% it is a substantial middle-weight slice of the exam. Hardware alone does nothing useful; software is what turns a pile of components into something that writes documents, browses the web, or plays music. This domain covers the layers of software — the operating system that manages the whole device, and the applications you use on top of it — plus the modern reality that software increasingly runs somewhere other than your own computer. For a beginner this is friendly terrain, because you already use all of it every day; the exam just gives it names and structure.

Start with the operating system, because it is the software everything else depends on. The operating system (Windows, macOS, Linux on computers; Android and iOS on phones) is the manager that sits between you and the hardware: it starts the machine, controls the processor, memory, and storage, manages files, runs your applications, and provides the interface you interact with. The exam wants you to recognize the major operating systems, understand that each runs its own kinds of software, and know the everyday tasks an operating system handles — managing files and folders, installing and removing programs, handling user accounts, and controlling devices like printers. This is the same file-and-settings territory you already navigate; naming it as 'the operating system's job' is the shift the exam asks for.

On top of the operating system sit applications — the programs that do specific jobs. The domain groups them by purpose: productivity software (word processors, spreadsheets, presentation tools), communication and collaboration tools (email, messaging, video calls), browsers for the web, and specialized or business software. A key distinction is how software is delivered and licensed: some you install and own outright, some you subscribe to, and a growing share you simply use through a browser without installing anything. Understanding that 'an app' can mean a program on your disk, an app on your phone, or a website you log into is central to this domain — and to recognizing the trade-offs among them.

That delivery question is where the modern shape of the domain lives: the difference between a local application, a web application, and a cloud service. A local application is installed on your own device and runs there, using your device's own processor and storage. A web application runs mostly on a distant server and you reach it through a browser — your email or a document editor you use without installing anything. A cloud service is computing you rent and use over the internet rather than owning. The trade-offs recur: local apps work offline and keep data on your machine but must be installed and updated per device; web and cloud apps update themselves centrally and reach from anywhere but need a connection and put your data on someone else's servers. The exam checks whether you can match a described situation to the right model — which the lab below has you feel by comparing the same kind of tool in all three forms.

The domain also covers the practical software lifecycle: installing, configuring, updating, and removing software, and doing it safely. Software gets updates for features and, importantly, for security fixes — keeping software current is one of the simplest protections against attack, tying this domain back to security. Configuration means adjusting a program's settings to fit your needs, and safe removal means uninstalling cleanly rather than just deleting an icon. Underlying all of it is the habit of getting software only from trusted sources, because an application is code running on your machine with real power — a theme the security domain develops and this one introduces.

Study this domain by looking at the software you already run through its lens: which of your tools are installed programs, which are websites you log into, and which are phone apps? Which update themselves and which ask you to? The lab below has you compare a document or notes tool in three forms — a local app, a web app, and a cloud-synced service — so the local/web/cloud distinction stops being abstract and becomes a difference you have personally observed. As with every domain on this track, read the official CompTIA Tech+ objectives for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.

Learn it free

Lab: compare a local app, a web app, and a cloud service you already use

Make the local-versus-web-versus-cloud distinction concrete by comparing the same kind of tool — say, taking notes or editing a document — in all three forms, using software you already have. You will observe the real trade-offs (offline use, updates, where your data lives) rather than just reading them.

Free tools

  • A local application already on your computer (for example a text editor, Notepad, TextEdit, or an installed word processor) — free/already installed
  • A web application you can open in a browser (for example a free web-based document or notes tool you already use, opened at its website) — free
  • Optional: a cloud-synced note or file app you already use on your phone or computer (the same account on two devices) — free tiers are fine
  • Any modern web browser — free, already on your machine

Steps

  1. Pick one task you understand — writing a short note or a to-do list works well. You will do the same task three ways.
  2. First, the LOCAL app. Open a program installed on your computer (Notepad on Windows, TextEdit on Mac, or any installed editor). Type a few lines and save the file. Notice where it saved — a folder on your own drive. This ran entirely on your machine, using your processor and storage, and it works with the internet turned off.
  3. Test the offline point: disconnect from Wi-Fi (or note that you could) and confirm the local app still works perfectly. Local apps do not need the internet to run. Reconnect when done.
  4. Second, the WEB app. Open your browser and go to a web-based document or notes tool you already use, at its website. Notice you did not install anything — the app loaded in the browser and runs mostly on a distant server. Type a few lines; it likely saves automatically to your account online.
  5. Test the connection point: a web app generally needs the internet to load and save. Notice that your work here lives on the provider's servers, reachable from any device where you log in — a different trade-off from the local file sitting only on your drive.
  6. Third, the CLOUD-synced service (optional but ideal). Open a note or file app that syncs across devices under one account. Create a note on one device, then open the same account on a second device (or the web version) and watch the note appear. That automatic appearance is cloud sync — your data lives centrally and reaches all your devices.
  7. Now compare all three on paper: Where does it run? (your device / a server / the cloud). Does it work offline? (yes / no / partly). Where does your data live? (your drive / their servers). Who updates it? (you install updates / it updates itself centrally). Fill in each cell from what you just observed.
  8. Read your comparison and connect it to a real choice: when would you want the local app (offline, private, on one machine), and when the web or cloud version (reach from anywhere, auto-updated, shared)? That judgment is exactly what this domain tests.
  9. Optional: check how each one updates. A local app usually prompts you to install updates; a web/cloud app just changes on its own because the provider updates the central copy. Seeing that difference explains why 'keep software updated' feels different for installed versus web software.

What you should see

The same simple task done three ways, and a filled-in comparison showing that the local app runs on your device and works offline with data on your drive, while the web and cloud versions run on distant servers, need a connection, update themselves, and keep your data reachable from anywhere. You have personally observed the local/web/cloud trade-offs this domain describes instead of memorizing them.

This lab practices the application-model concepts — local applications versus web applications versus cloud services, and their trade-offs — that Domain 3 (Applications and software) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: Use only software and accounts you already own or have legitimately signed up for, and only your own devices. Do not install software from untrusted sources for this lab — using tools you already have is the point. When you disconnect Wi-Fi to test offline behavior, reconnect afterward; make no other changes to your system.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. A user sees an old version of a web application after an update, while others see the new version. What software troubleshooting step is reasonable?
Check 2. A mobile app retrieves order status from a backend service over HTTPS. What software concept is likely involved?

Module 5 of 6 · domain 4 · 13% of the exam

Software development concepts

Fifth in our suggested order, per its 13% weight. Study it after the applications domain: once you know what software is, this domain peeks under the hood at how it is written — the logic and building blocks behind the apps you just categorized.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'how is software actually built' domain, and at 13% it is one of the lighter slices — but for a beginner it is often the most eye-opening, because it demystifies what programmers do. You will not be asked to write real code on Tech+. Instead, the exam checks that you understand the ideas programming is made of: how instructions are organized, the basic building blocks every language shares, and how a plain-English description of a task turns into logic a computer can follow. Think of it as learning to read the recipe, not to cook the whole meal — enough to reason about software and talk to the people who build it.

Start with the idea of a program as a set of instructions executed in order. At its simplest, code is a sequence of steps the computer follows one after another — much like a recipe or a set of directions. From that starting point, three ideas let programs do anything interesting. Sequence is doing steps in order. Selection (branching) is making a decision — 'if this is true, do that; otherwise do something else' — which is how software responds differently to different situations. Iteration (looping) is repeating steps — 'do this for each item' or 'keep doing this until done' — which is how a program handles many things without you writing each one out. Nearly every program you have ever used is built from these three patterns, and recognizing them in a described task is a core exam skill.

Next come the building blocks that hold and move information through a program. A variable is a named container that stores a value you can read and change — think of it as a labeled box. Values have types (the same whole-numbers, decimals, true/false, and text you met in Domain 1), and the type matters because it decides what you can do with a value. Constants are values that do not change. Functions are named, reusable chunks of logic you can call by name whenever you need them, so you write a piece of behavior once and use it many times. These are the nouns and verbs of programming, and the exam expects you to recognize each from a plain description.

The domain also covers how logic gets expressed and organized. Pseudocode is writing out the steps of a program in structured plain language before turning it into a real programming language — a way to think through logic without worrying about exact syntax, and exactly what this domain's lab has you do. Flowcharts express the same logic visually, with boxes for steps and diamonds for decisions. The exam also introduces broad categories of programming languages and approaches at a recognition level — that there are different languages for different jobs, that some code is compiled ahead of time and some interpreted as it runs, and that markup and query languages (for structuring web pages or asking databases questions) are their own things. You are placing these ideas, not mastering any language.

Finally, the domain frames the value and organization of code beyond a single script. Ideas like breaking a big problem into smaller pieces, reusing logic through functions rather than repeating it, and organizing related data together make software understandable and maintainable — the difference between a tangle nobody can fix and a program that can grow. The domain connects back to problem-solving: writing software is really structured problem-solving, taking a fuzzy human goal and turning it into unambiguous steps a machine can follow without judgment of its own. That translation skill — from vague intention to precise instructions — is the heart of what this domain teaches, and it is useful far beyond programming.

Study this domain by thinking in steps: take an everyday task and break it into an exact, ordered list of instructions precise enough that someone (or something) with no common sense could follow it — that is what programming feels like. The lab below has you write pseudocode for a simple everyday decision, including a branch and a loop, so sequence, selection, and iteration stop being terms and become logic you have authored yourself. As with every domain on this track, read the official CompTIA Tech+ objectives for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.

Learn it free

Lab: write pseudocode for an everyday task (sequence, decision, and loop)

Turn programming logic from vocabulary into something you have authored: write pseudocode — structured plain-language steps — for a simple everyday task, deliberately including a sequence of steps, a decision (if/else), and a loop (repeat). You will feel sequence, selection, and iteration as logic you built, not terms you memorized. No coding tools required.

Free tools

  • Any free text editor or notes app (Notepad, TextEdit, any editor, or a Google Doc) — or paper and a pen

Steps

  1. Pick a small everyday task with a decision in it. A good example: 'decide what to wear based on the weather,' or 'make a cup of tea,' or 'sort a pile of mail.' We will use 'decide what to wear.'
  2. Write the SEQUENCE first — the plain ordered steps, one per line, as if instructing someone with no common sense. For example: 1) Check the weather. 2) Choose an outfit. 3) Get dressed. 4) Leave. Number them so the order is explicit. This is sequence: steps executed in order.
  3. Add a DECISION (selection) using if/else in plain words. Replace step 2 with a branch, for example: 'IF the temperature is below 10 degrees, THEN wear a coat; ELSE IF it is raining, THEN take an umbrella; ELSE wear a light jacket.' Indent the branches so the structure is visible. You have written selection — the program doing different things in different situations.
  4. Add a LOOP (iteration). Introduce a repeated action, for example: 'FOR each item on my checklist (keys, phone, wallet), check that I have it; IF an item is missing, THEN go get it.' The word FOR-each signals a loop that repeats the same check for every item. You have written iteration — repeating steps without writing each one out.
  5. Introduce a VARIABLE to make the logic general. At the top write: 'SET temperature = today's temperature' and 'SET is_raining = true or false.' Now your if/else refers to these named containers rather than fixed values — that is a variable, a labeled box holding a value your logic reads.
  6. Read your pseudocode top to bottom as if you were the computer: follow it literally, with no common sense, for a cold rainy day (temperature = 5, is_raining = true). Does it produce a sensible outcome? If a literal reading gives a silly result, your logic has a gap — fix it. This is debugging in miniature.
  7. Now run it a second time for a different case — a warm dry day (temperature = 25, is_raining = false) — and confirm the branches send you down the right path. Testing the same logic against different inputs is exactly how real programs are checked.
  8. Optional: draw the same logic as a simple flowchart — rectangles for steps, a diamond for each decision, arrows for the flow, and a loop-back arrow for the repeated check. Seeing your pseudocode as a diagram connects the two ways this domain expresses logic.
  9. Optional: convert one line of your pseudocode into how it might look in a real language, informally — e.g. 'if temperature < 10:' — just to notice that real code is your pseudocode with stricter punctuation. You are not learning a language here, only seeing that the gap between plain logic and code is smaller than it looks.

What you should see

A short piece of pseudocode you wrote that contains a numbered sequence, an if/else decision, a for-each loop, and at least one variable — plus the experience of 'running' it by hand for two different inputs and watching it take different paths. You have authored sequence, selection, and iteration yourself, which is the core of what this domain tests.

This lab practices the programming-logic building blocks — sequence, selection (branching), iteration (loops), variables, and pseudocode — that Domain 4 (Software development concepts) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: This is a pen-and-paper (or text-editor) thinking exercise — it writes no real code, installs nothing, and touches no system. You only need a place to write. There is nothing here that can affect your device or anyone else's.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. A script should send a warning only when disk usage is above 90 percent. Which programming concept is needed?
Check 2. Two people edit a script and need to track changes and revert mistakes. Which development practice helps?

Module 6 of 6 · domain 5 · 13% of the exam

Data and database fundamentals

Last in our suggested order, per its 13% weight — one of the lightest domains, and among the most concrete. It reads most easily once you understand software (Domain 3) and a little logic (Domain 4), which makes it a satisfying place to finish: you can build every idea in a free spreadsheet.

What this domain actually covers

Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA Tech+ (FC0-U71) certification page

This is the 'how is information organized and stored so we can use it' domain, and at 13% it is one of the lighter slices — but it is quietly one of the most important, because data is what most modern software exists to manage. This domain covers what data is, the difference between raw data and useful information, how data is structured so it can be searched and related, and the basics of the databases that hold it. For anyone coming from an office, finance, or operations background, this is welcoming territory: if you have ever used a spreadsheet, you already have a foothold on almost everything here.

Start with the distinction the domain is built on: data versus information. Data is raw facts on their own — a list of numbers, a pile of dates, a column of names — meaningful only once you organize and interpret them. Information is data put in context so it answers a question: '4,000' is data, but 'we sold 4,000 units in June, up from 3,000 in May' is information. The exam wants you to appreciate that the value is in the organization and interpretation, which is why the rest of the domain is about structuring data so it can become information. Related ideas include how data is collected, where it lives, and the difference between structured data (neatly organized in rows and columns) and unstructured data (documents, images, free text) that does not fit a tidy grid.

The heart of the domain is the vocabulary of structured data, best pictured as a table — exactly what a spreadsheet or a database table is. A table is made of records (the rows — one per thing, such as one customer per row) and fields (the columns — one per attribute, such as name, email, or city). Each field has a data type, constraining what it can hold (a date field holds dates, a number field holds numbers), which ties directly back to the data types from earlier domains. A special field, the primary key, uniquely identifies each record so you can always tell one row from another — a customer ID that no two customers share. Grasping records, fields, and a primary key is most of what this domain asks, and the lab below has you build all three by hand.

From single tables the domain steps up to databases — organized collections of data designed to be stored, searched, and updated efficiently. The exam distinguishes the common relational database, which organizes data into related tables (customers in one table, their orders in another, linked by a shared key so you avoid repeating information), from non-relational databases built for other shapes of data and very large scale. The relational idea — splitting data across tables and linking them by keys rather than cramming everything into one giant sheet — is the single most important structural concept here, because it is how real systems keep data consistent and avoid duplication. You are recognizing the idea, not designing a schema.

Finally, the domain covers what you do with stored data and how you keep it safe. Databases are queried — asked questions — to retrieve exactly the records you want, and while you are not expected to write query language on Tech+, you should recognize that a query language (like SQL) is how people ask a database questions and that the basic operations are creating, reading, updating, and deleting records. The domain also stresses protecting data: backing it up so it survives a failure, controlling who may read or change it, and the importance of data integrity (the data staying accurate and consistent) and privacy (handling personal data responsibly). These protection ideas connect straight to the security domain — data is usually the thing security exists to protect.

Study this domain by building the thing it describes: a small table is the clearest teacher. Open a free spreadsheet, put attributes across the top as fields, enter a few rows as records, and pick a column that uniquely identifies each row as your primary key. The lab below walks you through exactly that, plus sorting and filtering to turn raw rows into an answer — which is the data-to-information story of this whole domain in a few minutes. As with every domain on this track, read the official CompTIA Tech+ objectives for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.

Learn it free

Lab: build a small table in a free spreadsheet and find its fields, records, and primary key

Make the core database vocabulary concrete by building it yourself: create a small table in a free spreadsheet, then identify its fields (columns), records (rows), and a primary key (the column that uniquely identifies each row) — and turn raw rows into an answer by sorting and filtering. This is the data-to-information story of Domain 5, built by hand, for free.

Free tools

  • Any free spreadsheet app you already have or can use free: a local one (LibreOffice Calc, or a spreadsheet already installed) or a free web-based spreadsheet (for example Google Sheets) — free
  • Any modern web browser if you use a web-based spreadsheet — free, already on your machine

Steps

  1. Open a blank spreadsheet. You are going to build a small table of, say, five people — a mini 'contacts' or 'students' table.
  2. Create the FIELDS. In the first row, type column headers: for example id , name , city , signup_date . Each column is a field — one attribute of the thing you are storing. Notice each field naturally has a type: id and dates and text are different kinds of value, echoing the data types from earlier domains.
  3. Create the RECORDS. Fill in five rows below the headers, one per person — each complete row is a record, all the fields for one thing. After this you have a real table: fields across the top, records down the side.
  4. Choose a PRIMARY KEY. Look at your columns and ask: which one uniquely identifies each row, with no two rows ever sharing it? Name is a poor choice (two people can share a name); the id column, where you give each person a unique number (1, 2, 3, 4, 5), is a good primary key. Fill the id column with unique numbers and note why it, not name, is the key.
  5. Prove why the key matters: deliberately give two rows the same name but different ids. You can still tell them apart by id — that is exactly the job a primary key does, guaranteeing every record is distinguishable.
  6. Now turn data into information by SORTING. Select your table and sort it by the city column (Data → Sort). Watch the rows reorder. The same facts, organized differently, now answer 'who is grouped in which city?' — data becoming information through organization.
  7. Turn data into information by FILTERING. Apply a filter (Data → Create a filter / AutoFilter) and show only rows where city equals one value. You have just 'queried' your table — asked it a question and gotten back only the matching records. That is the everyday version of what a database query does.
  8. Reflect on the relational idea without leaving the spreadsheet: imagine each person also has many orders. Cramming all their orders into this one table would repeat their name and city over and over. A second 'orders' table linked back to this one by the person's id (the key) avoids that repetition — that linking-by-key is the heart of a relational database.
  9. Optional: add a column with a deliberate error (a date typed into the name column, or a blank id) and notice how it breaks the table's consistency. That is a data-integrity problem — the reason databases constrain what each field may hold.

What you should see

A small, real table with labeled fields (columns), records (rows), and a primary-key column that uniquely identifies each row — plus the same data sorted and filtered to answer a question. You have built the records-fields-key vocabulary by hand, watched raw data become information through organization, and reasoned about why related tables beat one giant sheet.

This lab practices the data-and-database fundamentals — data versus information, records, fields, primary keys, querying, and the relational idea — that Domain 5 (Data and database fundamentals) of the official CompTIA Tech+ (FC0-U71) objectives covers; see the official objectives for CompTIA's own wording.

Stay safe & legal: Use a spreadsheet and account you own, and invent fake sample data (made-up names and dates) rather than using anyone's real personal information — good data-privacy habit and part of what this domain teaches. This lab only creates a file you control; it touches no other system and installs nothing beyond a spreadsheet app you already have.

Check yourself

2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.

Check 1. A customer table needs a value that uniquely identifies each record. Which database concept fits?
Check 2. A user wants only open tickets assigned to one team from a database. What basic data operation is needed?

Skills you’ll build

Studying CompTIA Tech+builds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:

Before you book the exam

Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.

Exam facts (cited)

A free, source-cited study companion built on CompTIA's published Tech+ (FC0-U71) objectives — not official training, not a pass guarantee. Verify the current objectives on the official CompTIA Tech+ page before your exam.

Sources used on this page

Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by CompTIA.