Answer every kind of Paper 1 Section A question, from definitions and calculations to SQL and truth tables, and write balanced discuss, evaluate and to-what-extent answers that reach the top markband.
Paper 1 Section A tests theme A of the course: A1 Computer fundamentals, A2 Networks, A3 Databases and A4 Machine learning. There is no Python or Java to read or write in Section A, but there are calculations, truth tables, diagrams and SQL queries, and every question ends with parts that ask you to explain, discuss or evaluate. All questions are compulsory, so there is no choosing your favourite topic.
The skills that earn marks here are precise vocabulary, clear working, careful use of the scenario in each question, and well-structured extended answers. Each can be practised, and each has a recognisable shape of full-mark answer.
The guide describes Section A as extended-response questions. In practice, based on how IB Computer Science papers have been set before, each question is built around one scenario, such as a school network, a shop's database or a hospital's machine learning system, and broken into lettered parts of rising difficulty.
The anatomy of a typical question shows the pattern. The marks rise as the command terms move from AO1 to AO3, and the last part is almost always the longest.
Part | Command term | Marks | What it tests |
|---|---|---|---|
Stem | A school library's database and network, with an extract of two tables | ||
(a) | State / Define / Identify | 1–2 | A term or fact from the topic |
(b) | Outline / Describe | 2–3 | How a component, protocol or process works |
(c) | Construct / Calculate | 3–4 | An SQL query, truth table, diagram or calculation from the stem's data |
(d) | Explain | 3–4 | A reason or mechanism, applied to the scenario |
(e) | Discuss / Evaluate / To what extent | 4–6 | A balanced judgement on a decision in the scenario |
The pattern is inferred from earlier IB Computer Science papers; no 2027 paper is public. Expect variations.
At HL the same questions appear with extra parts on HL-only content, such as pipelining, the TCP/IP model, SQL aggregate functions or machine learning approaches. These HL parts can sit in the middle of a question, so HL students should read every part before starting. The page "What changes at HL" lists the HL-only statements and the parts they are likely to produce.
Each type of Section A question has its own way of earning and losing marks. The worked examples use the school library scenario from the anatomy table, with two tables:
Book (book_id, title, author)
Loan (loan_id, book_id, student_id, due_date)
State, Define, Identify and List parts are worth 1–2 marks each, and together they add up to a significant share of the paper. They reward exact vocabulary. A definition must contain the qualifying words that make it true of this term and no other: a Structured Query Language (SQL) definition that says only "a language for databases" doesn't say what the language does.
Build definitions from the glossary of each subtopic, and learn them word for word only where the precise wording matters (primary key, foreign key, protocol, latency, overfitting). For the rest, learn the key qualifying phrases.
Calculate parts can appear in A1 (binary and hexadecimal conversions, file sizes, compression ratios), A2 (transmission times, subnet sizes) and, at HL only, A4 (accuracy, precision, recall and F1 score). Examiners usually give a mark for the method and a mark for the answer, so working is worth marks on its own.
Three habits prevent most lost marks:
Write the formula in words before the numbers, for example "time = file size in bits ÷ bandwidth in bits per second".
Convert units first. File sizes are usually in bytes (B) and bandwidth in bits per second (bit/s), so multiply bytes by 8. Use the prefix the question defines: 1 MB = 1,000,000 bytes and 1 MiB = 1,048,576 bytes.
Give the units with the answer. "36" is not the same answer as "36 seconds".
Construct questions on logic (subtopic A1.2) ask for a truth table, a circuit or a simplified expression. Truth tables are usually marked by row groups or by columns, so a systematic layout matters more than speed.
List the inputs in binary counting order (000, 001, 010, … 111), so no row is missing or repeated.
Add a column for each intermediate result (such as A AND B or NOT C), then the output. Intermediate columns earn method marks and catch your own mistakes.
For a circuit, use the standard gate shapes, label every input and the output, and make every connection clear. An ambiguous joint is not credited.
Diagram questions include a CPU block diagram with its registers and buses, a network diagram with devices, an entity–relationship diagram (ERD), and normalised table structures. Marks go to the right components, the right connections and the labels; neatness earns nothing but ambiguity loses marks.
Diagram | What earns marks |
|---|---|
CPU block diagram | CU, ALU and named registers inside the CPU; memory outside; address bus one-way from CPU to memory, data and control buses two-way, all labelled |
Network diagram | Each device named (switch, router, wireless access point, server); connections shown; the internet link through the router |
ERD | Entities named, relationships drawn with the correct cardinality (one-to-many), many-to-many resolved by a link entity where asked |
Table structures | Every table with its fields; primary key underlined; foreign keys marked and pointing to the right table |
SQL is the only "code" in Paper 1. You write it without a database to test it, so build each query clause by clause and check it against the tables in the stem.
SELECT: which columns does the question ask for? Use the exact field names from the stem.
FROM and INNER JOIN … ON: which tables hold those columns, and which key links them?
WHERE: which rows? Text values go in single quotes; numbers don't.
ORDER BY: is an order asked for? ASC is the default; DESC reverses it.
SELECT Book.title, Loan.due_date
FROM Book
INNER JOIN Loan ON Book.book_id = Loan.book_id
WHERE Loan.student_id = 'S104'
ORDER BY Loan.due_date ASC;Explain parts are usually worth 3–4 marks and need linked chains: a point, then its cause or effect. In Section A, the context from the stem is often what turns a description into an explanation. For a database question, "this avoids redundancy" is a general truth; "so a book's title is stored once, in Book, and not repeated in every loan" is an explanation applied to the scenario.
Section A and Section B of Paper 1 are sat together, with no break between them, so the split of time is yours to manage. Both papers allow 1.5 minutes per mark.
Level | Section A | Section B (case study) |
|---|---|---|
SL | 38 marks ≈ 57 minutes | 12 marks ≈ 18 minutes |
HL | 56 marks ≈ 84 minutes | 24 marks ≈ 36 minutes |
Check the clock at the end of each Section A question. If you are more than a few minutes behind, write shorter answers for the low-mark parts of the next question, not for the long parts at the end, which carry the most marks per minute of planning.
The last part of most Section A questions asks for a judgement, and so do the AO3 parts of Section B (short at SL, extended at HL). These parts are usually worth 4–6 marks and are often marked as a whole against level descriptors, not point by point.
No markband for the 2027 papers is public. Based on markschemes from the previous course, a 6-mark discuss or evaluate part is likely to be judged on four qualities: knowledge of the technology, use of the scenario, balance of arguments, and a supported conclusion. The table describes illustrative bands written for practice, not the IB's wording.
Band | Illustrative description |
|---|---|
0 | Nothing relevant |
1–2 | Some relevant points, mostly listed; little or no use of the scenario; one-sided |
3–4 | Relevant, mostly accurate points applied to the scenario; both sides present but not weighed, or a conclusion with no reasons |
5–6 | Accurate technical points, consistently applied to the scenario; both sides weighed; a clear conclusion supported by the argument |
The key feature is that more points do not move an answer up a band. A list of eight advantages stays in the lower bands because it lacks balance and judgement; four well-chosen points, two on each side, weighed and concluded, reaches the top.
The answer-planning flowchart shows the route for every part, with the extra steps that a judgement question needs. Planning takes a minute and saves the most common failure, a list with no conclusion.


For a 6-mark judgement, a paragraph plan like this fits into about nine minutes:
Claim and context (one or two sentences): what the decision is and who it affects.
Technical explanation: how the technology works, in enough detail to show understanding.
Arguments for, applied to the scenario: two developed points.
Arguments against, applied to the scenario: two developed points.
Weighing: which matters more in this scenario, and why. This is the step most answers miss.
Conclusion: a direct answer to the question, with the reason, and if useful a condition ("acceptable if…").
Judgement questions in theme A often concern ethics and impact, especially in A4 Machine learning, where subtopic A4.4 asks you to discuss ethical implications directly. Precise vocabulary makes points shorter and easier to credit. The terms that recur most are stakeholders, privacy, consent, algorithmic bias (often traced to training data), accountability, transparency, explainability, environmental impact, the digital divide, data minimisation and keeping a human in the loop.
Term | Use it when |
|---|---|
Stakeholder | Naming who is affected: users, the organisation, staff, the public, data subjects |
Privacy | Personal data is collected, stored, shared or inferred |
Consent | People have, or haven't, agreed to how their data is used |
Algorithmic bias | A system's outputs are systematically unfair to a group, often from its training data |
Accountability | Asking who is responsible when an automated decision is wrong |
Transparency and explainability | Whether people can see how a system reaches its decisions |
Security | Whether data and systems are protected from unauthorised access |
Environmental impact | Energy use, hardware manufacture, electronic waste |
Digital divide | Some groups gain less from, or are excluded by, a technology |
Data minimisation | Arguing that only the data needed should be collected |
Human-in-the-loop | Proposing that a person reviews automated decisions |
Each term is only worth a mark when it is tied to the scenario. "This raises privacy issues" is a label; "the cameras record every passenger's face, including children's, without asking, which is a privacy issue because faces are biometric data that can identify a person for life" is an argument.
Three sample answers, written for practice, show the markbands at work. They answer the same question. Read each one with the band descriptions in mind before opening the commentary.
The strong answer is longer than the middle one, but the extra length earns marks only because of what it adds: a weighing paragraph that compares the two sides directly, and a conclusion that follows from it.
Evaluate asks you to weigh strengths and limitations and reach a judgement, so it has the same shape as Discuss, usually in fewer marks. To what extent asks for a judgement of degree: answers such as "largely, but not entirely, because…" or "only to a limited extent, since…" fit the term better than a yes or no.
Most marks lost in Section A come from answering a different question from the one asked, or from answering it without the scenario.
Two smaller habits also cost marks across the paper. Writing "it" and "this" without saying what they refer to makes points ambiguous, and examiners can't credit what they have to guess. Using informal words ("the computer looks for the data") instead of the technical term ("the control unit fetches the instruction") makes correct ideas sound imprecise.
I can describe how a Section A question is built and where the high-mark parts usually are.
I read every part of a question before I start writing.
I write definitions with the qualifying words, not with an example alone.
I show the formula, unit conversions and units in every calculation.
I build truth tables in binary order with intermediate columns.
I can label CPU, network and ER diagrams with every component and connection the marks need.
I write SQL clause by clause, with exact field names, joins and quoted text values.
I apply every explain point to the scenario in the stem.
I can pace Section A and Section B in one sitting at 1.5 minutes per mark.
I plan judgement answers with both sides, a weighing step and a supported conclusion.
I use ethics vocabulary tied to named stakeholders in the scenario.
With a free account, Augment remembers where you stopped in the notes and which questions you have marked.