Domain weights and how to prioritize

Noor has about four months before her planned exam date and roughly five hours a week to study, once her shifts and the cert club are counted. That is a real but limited budget, and Lorna wants her to spend it where it earns the most. The tool for that is the domain list in the exam objectives. Every CompTIA exam is divided into domains, each with a weight that says roughly how much of the exam it covers. Reading those weights properly, and combining them with an honest view of your own strengths, turns a vague intention to "study everything" into a plan that can be checked week by week.

The six Tech+ domains

The Tech+ objectives are organized into six domains. Domain 1, IT concepts and terminology, covers notational systems such as binary and hexadecimal, units of measure, the basics of computing, and the troubleshooting method. Domain 2, infrastructure, covers computer components, storage, peripherals, networking, internet service types, wireless networks, and virtualization and cloud. Domain 3, applications and software, covers operating systems, file management, application types and licensing, web browsers and common uses of artificial intelligence. Domain 4, software development concepts, covers programming language categories, logic and organizational techniques, data types, identifiers, containers, functions and objects. Domain 5, data and database fundamentals, covers the value of data, database structures and how databases are used. Domain 6, security, covers confidentiality, integrity and availability, authentication and authorization, password practices, device and browsing security, threats and backups.

CompTIA's main page uses the name "tech concepts and terminology" for domain 1, the catalogue entry for this course calls it "technology concepts", and the objectives document calls it "IT concepts and terminology". All three names mean the same domain. Small naming differences like this appear across study materials, and they are another reason to keep the official objectives document open beside any course or video.

Reading the weights sensibly

A weight is a share of the exam, not an exact number of questions. With a maximum of 70 questions, a domain weighted 24 accounts for roughly 17 questions and a domain weighted 13 for roughly 9. CompTIA does not publish the exact count per domain for each exam form, and the two official pages disagree by one or two points for some domains, so the sensible approach is to plan with round numbers. Infrastructure is clearly the largest domain, security and applications come next, and the other three are similar in size. No domain is small enough to skip: even a domain weighted 13 is about one question in every eight.

The disagreement between pages is a good example of how to plan under uncertainty. Whichever set of weights is correct, infrastructure is largest and the three 13-or-14 domains are about equal. A plan that gives infrastructure the most time and spreads the rest sensibly will be right under both sets of numbers. Planning that depended on the difference between 13 and 14 would be false precision. Lorna calls this "planning to the shape, not the decimals."

Weight is only half the picture

A domain's weight says how much it matters on the exam. Your confidence in that domain says how much study it needs. Combining the two gives a far better plan than either alone. A domain with a high weight where you are already strong needs maintenance and practice questions, not a full relearning. A domain with a modest weight where you are weak can still cost you the exam, because nine questions answered badly is a lot of lost points. The domains that need the most attention are the ones that are both heavily weighted and weak.

Lorna asks Noor to rate herself honestly on each domain from 1 ("I would mostly be guessing") to 5 ("I could teach this"), using the objectives document line by line rather than gut feeling. Years on the circulation desk have made her confident with peripherals, printers and applications, and COMP-110 filled most of the infrastructure gaps. Software development is new to her, and she still mixes up database keys. Her ratings are: IT concepts 4, infrastructure 3, applications 4, software development 2, data 2, security 3.

Turning ratings into hours

One simple way to divide study time is to give each domain a priority score equal to its weight multiplied by its gap, where the gap is how far the self-rating is below 5, plus one so that no domain gets zero time. Each domain's share of the total priority then becomes its share of the study hours. This is only a starting point, and it should be adjusted after each practice test, but it is much better than studying in the order of the textbook. The short program below does the arithmetic for Noor's 80 hours, using the main page weights.

weights = {"IT concepts": 13, "Infrastructure": 24, "Applications": 18,
           "Software development": 13, "Data": 13, "Security": 19}
confidence = {"IT concepts": 4, "Infrastructure": 3, "Applications": 4,
              "Software development": 2, "Data": 2, "Security": 3}
total_hours = 80

priority = {d: weights[d] * (5 - confidence[d] + 1) for d in weights}
total_priority = sum(priority.values())
for d in weights:
    hours = total_hours * priority[d] / total_priority
    print(f"{d:22s} priority {priority[d]:3d}  hours {hours:5.1f}")
print("Total priority:", total_priority)

IT concepts            priority  26  hours   7.1
Infrastructure         priority  72  hours  19.5
Applications           priority  36  hours   9.8
Software development   priority  52  hours  14.1
Data                   priority  52  hours  14.1
Security               priority  57  hours  15.5
Total priority: 295

The result surprises Noor. Infrastructure, the largest domain, gets a lot of time even though she rated it 3, because its weight is so large. Software development and data, the two domains she rated 2, get about as much each as security, even though their weights are smaller. IT concepts and applications, where she is confident, still get about seven and ten hours, enough for practice questions and a final review. She rounds the numbers and writes them into her plan: 20 hours for infrastructure, 15 for security, 14 each for software development and data, 10 for applications and 7 for IT concepts, which adds up to her 80.

Working through the objectives document

Weights tell you where to spend time; the objectives document tells you what to study within each domain. Each domain is broken into numbered objectives, such as 2.3 for storage or 6.2 for authentication, and each objective lists the topics and terms that may appear. A good habit is to turn the document into a checklist. Go through every bullet, mark each one as known, shaky or unknown, and add a page reference to the course lesson or notes where it is explained. That checklist becomes the agenda for every study session and the final review in lesson 12.

The objectives document also signals the depth expected. Verbs matter. An objective that says a candidate should "explain" or "compare" something expects understanding of how and why, not just recognition of a term. An objective that lists a set of items, such as types of malware or internet service types, is a reliable sign that questions will ask candidates to tell those items apart. When an objective lists examples, every listed example is fair game.

From weights to a weekly rhythm

Hours on paper only matter if they turn into sessions in a calendar. Lorna suggests a weekly rhythm rather than a strict domain-by-domain sequence. Each week, about two thirds of the time goes to the current priority domain, studied from the objectives checklist with notes and examples. The remaining third goes to mixed review: a short set of practice questions drawn from every domain, including ones already covered. Mixing domains feels harder than working through one topic at a time, but research on learning consistently finds that mixed, spaced practice produces better long-term recall than blocked practice, and it also mirrors the exam, where questions from different domains arrive in no particular order.

Noor maps her plan onto the weeks from mid-November to early March. Infrastructure comes first because it is largest and because COMP-110 is fresh in her memory. Software development and data follow, because they are her weakest and she wants time for them to settle before the exam. Security comes next, then a lighter pass through applications and IT concepts, and the final three weeks are reserved for full practice tests, gap closing and the final week plan in lesson 12. She writes the plan on one page and pins it above her desk, with a box to tick at the end of each week. A plan that can be seen every day is far more likely to be followed than one saved in a folder.

Common prioritizing mistakes

The most common mistake is studying in comfort order: spending hours on the topics you enjoy and postponing the ones you find dull or difficult. Lorna has seen many candidates who love networking spend half their time on infrastructure and then lose the exam on software development and data, which together are about a quarter of the questions. A second mistake is chasing rare details. An hour spent memorizing an obscure specification number is an hour not spent on a whole objective that will certainly appear. A third is never updating the plan. Self-ratings at the start are guesses; practice tests turn them into evidence, and the plan should follow the evidence.

The last mistake is the opposite of the first: ignoring strengths completely. A domain where you feel confident still needs practice questions, because confidence and exam performance are not the same thing. Some of the most damaging errors in practice tests come from questions in a candidate's favourite area, answered too quickly. Every domain gets some time, and every domain gets tested in practice.