top of page
white-Photoroom-80_edited.png

Latest Cambridge AS & A Level Computer Science 9618 Past Papers & Mark Schemes (Updated 2026)

Sep 1
19 min read

Updated: Sep 3

Cambridge International A Level Computer Science revision hub

Everything you need to revise smarter for CIE A Level Computer Science — past papers, mark schemes, worked answers, and teacher tips in one place.


Cambridge International A Level Computer Science past papers

Past Papers

Download past papers and mark schemes to practice effectively



Cambridge International A Level Computer Science examiner guidance

Examiner Tips

Understand what examiners look for and how to earn top marks


Cambridge International A Level Computer Science student Q&A

Q&A

Get answers to commonly asked questions from students like you



CIE A Level Computer Science Past Papers (June 2026)

2026 CIE A Level Computer Science (June)

Downloads

June 2026 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/11)

June 2026 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/12)

June 2026 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/13)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/21)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/22)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/23)

June 2026 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/31)

June 2026 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/32)

June 2026 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/33)

June 2026 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/42)

June 2026 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/43)



CIE A Level Computer Science Past Papers (October 2025)

2025 CIE A Level Computer Science (October)

Downloads

October 2025 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/11)

October 2025 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/12)

October 2025 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/13)

October 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/21)

October 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/22)

October 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/23)

October 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/31)

October 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/32)

October 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/33)

October 2025 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/41)

October 2025 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/42)

October 2025 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/43)


CIE A Level Computer Science Past Papers (June 2025)

2025 CIE A Level Computer Science (June)

Downloads

June 2025 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/12)

June 2025 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/13)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/21)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/22)

June 2025 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/23)

June 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/31)

June 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/32)

June 2025 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/33)

June 2025 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/42)

June 2025 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/43)


CIE A Level Computer Science Past Papers (October 2024)

2024 CIE A Level Computer Science (October)

Downloads

October 2024 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/12)

October 2024 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/13)

October 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/21)

October 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/22)

October 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/23)

October 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/31)

October 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/32)

October 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/33)

October 2024 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/41)

October 2024 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/42)

October 2024 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/43)


CIE A Level Computer Science Past Papers (June 2024)

2024 CIE A Level Computer Science (June)

Downloads

June 2024 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/12)

June 2024 Cambridge International AS & A Level Computer Science Paper 1: Theory Fundamentals (9618/13)

June 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/21)

June 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/22)

June 2024 Cambridge International AS & A Level Computer Science Paper 2: Fundamental Problem-solving and Programming Skills (9618/23)

June 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/31)

June 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/32)

June 2024 Cambridge International AS & A Level Computer Science Paper 3: Advanced Theory (9618/33)

June 2024 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/42)

June 2024 Cambridge International AS & A Level Computer Science Paper 4: Practical (9618/43)


Cambridge International A Level Computer Science teacher tips and revision advice

I have been teaching the A Level for a number of years now, and if there is one thing that still surprises me, it is how predictable the mark losses are. Not random, not unlucky — predictable. The same mistakes, paper after paper, student after student. Everything below are common mistakes students lose marks on, and everything below is fixable.


Tip 1: The scenario in the question is not decoration


This is one of the most consistent patterns I see, and it is frustrating because it is so avoidable. A student demonstrates perfectly good knowledge of a concept, writes a clean definition, and then scores half marks — because they wrote about the concept in the abstract rather than in the context the question gave them.


Here is what that looks like in practice. The question says: "A washing machine uses an embedded system. Describe the role of an embedded system in this context." A generic answer talks about embedded systems being dedicated to a specific task, having limited memory, and being programmed at the point of manufacture. All of that is correct. None of it mentions a washing machine. The examiner is looking for something like: the embedded system controls the motor to rotate the drum, monitors the water temperature sensor to regulate heating, and manages the timing of each wash cycle according to the selected programme.


Same underlying knowledge — completely different score. Get into the habit of treating the scenario in the question stem as something that applies to every part of your answer. If the question introduces a board game AI, an image-processing application, or a hospital booking system, that context does not disappear after the first line. It is the lens through which your entire answer should be written. Before you start writing, ask yourself: have I actually mentioned the thing they described?


If the answer is no, reread the question.


Tip 2: "Faster" and "better" are not technical explanations

A Level Computer Science rewards precision. Vague comparative language — faster, more efficient, more secure, better — tells an examiner almost nothing, and in most mark schemes it earns nothing either.


The problem is that these words feel like they are saying something meaningful, but they are skipping over the technical reasoning that actually earns the mark. "Faster" compared to what? By what mechanism? Under what conditions?


Here is the pattern to break:

  • Instead of "using more cores makes it faster" — write "additional CPU cores allow multiple threads to be processed simultaneously, reducing the time taken to complete parallelisable tasks."

  • Instead of "the system has better security" — write "data is encrypted using a symmetric key algorithm, meaning that even if intercepted, the data cannot be read without the correct decryption key."

  • Instead of "validation is used to validate data" — write "validation checks input data against a set of predefined rules — such as a range check or a format check — to ensure the data is reasonable and in the expected form before it is processed."


Notice what each of those replacements has in common: they explain the mechanism. Not just what happens, but how and why it happens at a technical level. That is what examiners are awarding marks for.


A useful habit before you finish any answer: read back through it and underline every claim. For each one, ask — have I explained the technical reason behind this? If you find yourself reading a sentence that ends without a "because" or a "which means that," it probably needs one.


Tip 3: Command words are instructions — read them carefully


Every question in this exam tells you exactly how much to write and at what depth. The command word is that instruction. Ignoring it — or misreading it — is one of the most straightforward ways to lose marks that were entirely within your reach.


The three you will see most often work like this:

  • Identify asks you to name or state something. One clear, correct term or phrase is sufficient. Adding lengthy explanation wastes time and earns nothing extra.

  • Describe asks you to give an account of something — how it works, what it consists of, what it does. A single sentence is almost never enough. You need multiple connected points that build a complete picture.

  • Explain goes one step further. It requires you to say not just what something is or does, but why or how. Every described point needs a follow-through — a "because," a consequence, a mechanism.


A particular trap worth knowing: in some questions, especially those asking for benefits or advantages, only your first answer will be marked. If you list three benefits and your strongest one is third, the examiner may only credit the first. Lead with your best point every time.


Before you begin writing, circle the command word and hold it in mind throughout your answer. Ask yourself: at the depth this word requires, have I actually finished answering?


Tip 4: When asked how an ADT is implemented, talk about the mechanics — not the behaviour


This is a distinction that catches a lot of students out, and it comes down to a very specific difference between two questions that look similar but are asking for completely different things.


"What is a stack?" — that is a question about behaviour. First-In, Last-Out. Items are pushed on and popped off the top. The most recently added item is the first to be removed.


"How is a stack implemented using an array?" — that is a question about mechanics. The examiner wants to see the underlying structure: the data storage, the pointer variables, and the step-by-step operations that make the abstract behaviour happen in practice.


When answering an implementation question, your answer should include the following kinds of detail. A 1D array is declared to store the data values. An integer variable — typically called TopOfStack — is declared to act as a pointer, tracking the index of the current top element. When a value is pushed onto the stack, TopOfStack is incremented by one and the new value is stored at that index in the array. When a value is popped, the value at the index pointed to by TopOfStack is retrieved and TopOfStack is decremented by one. Before pushing, you check whether TopOfStack equals the maximum array size to avoid overflow. Before popping, you check whether TopOfStack equals the initial empty value to avoid underflow.


That level of mechanical detail is what the question is asking for. The behaviour — FILO, pushing, popping — is the starting point, not the answer. Once you have stated the abstract behaviour briefly for context, move immediately into the implementation.


The same principle applies to linked lists. Mentioning that a linked list stores items in nodes is not enough — the examiner wants to see the two arrays (one for data, one for next pointers), the start pointer, the free space pointer, and how those components interact during insertion and deletion.


Tip 5: Pseudocode is a language — treat it like one


One of the things that makes pseudocode questions frustrating to mark is that the errors are almost always structural rather than conceptual. Students who clearly understand what the algorithm is supposed to do still drop marks because the code itself is syntactically wrong. That is entirely avoidable.


The three most frequent issues are these.


Missing closing statements. Every IF needs an ENDIF. Every WHILE needs an ENDWHILE. Every FUNCTION or PROCEDUREneeds an ENDFUNCTION or ENDPROCEDURE. These are not optional formatting choices — they are part of the syntax, and their absence will cost marks. Get into the habit of writing the closing statement at the same time as the opening one, before you fill in the body.


Mixing up ← and =. The arrow ← is the assignment operator — it stores a value into a variable. The equals sign = is for comparison, used inside conditions. Writing x = 5 when you mean x ← 5 is a meaningful error, not a minor slip. The examiner reads it as a comparison, not an assignment.


Using OUTPUT inside a function when the question requires a returned value. If you are writing a function — something that computes a result and hands it back to whatever called it — the correct statement is RETURN. OUTPUT prints to the screen. These are different operations with different purposes. A function that OUTPUTs its result instead of RETURNing it is fundamentally broken as a piece of code.


One more point on subroutines: functions should receive their data through parameters, not by prompting for input inside the function body. If a function contains INPUT x, that is a design problem. The value should be passed in when the function is called.

The Pseudocode Guide you have been given is not supplementary material — it is the specification. When in doubt about syntax, go back to it.


Tip 6: Memory and storage are not the same thing — and neither are data and information

These pairs of terms come up constantly in theory questions, and using one when you mean the other is a reliable way to lose marks that require no calculation and no complex reasoning — just precision.


Memory vs Storage


Memory refers to RAM — the temporary, volatile workspace the CPU uses to store the program currently being executed and the data it is actively working with. When the power is cut, RAM is wiped. Storage refers to secondary storage — hard disk drives, solid state drives, optical discs — where files and programs are kept permanently, regardless of whether the machine is on or off. When a question asks about the operating system managing memory, it is asking about RAM: allocation, virtual memory, paging, segmentation. When a question asks about saving files or accessing data between sessions, it is asking about storage. Conflating the two in an answer signals to the examiner that you have not made this distinction, and the marks reflect that.


Data vs Information


Data refers to raw, unprocessed facts — numbers, characters, symbols that have no inherent meaning on their own. Information is data that has been processed, structured, or contextualised so that it carries meaning. The temperature reading 37 is data. "The patient's body temperature is 37°C, which is within the normal range" is information. In exam answers, use data when referring to raw input or stored values, and information when referring to processed or interpreted output.


When revising these terms, do not just memorise the definitions — practise applying the correct word in sentences. The error almost always happens not in definition questions, where students are primed to be careful, but in longer answers where the terms appear incidentally and precision slips.


Tip 7: SQL rewards careful reading and deliberate structure


SQL questions divide students sharply — those who have practised writing full queries consistently score well, and those who have only read about SQL rarely do. The errors that appear most often fall into three categories.


Joining tables incorrectly


When a query draws from more than one table, the WHERE clause must include the condition that links them — typically matching a foreign key in one table to a primary key in another. Without this linking condition, the query produces a Cartesian product: every row in the first table paired with every row in the second, generating a large volume of meaningless results. The structure to internalise is this: for every additional table you add to your FROM clause, you need a corresponding join condition in your WHERE clause.


Confusing COUNT and SUM


These are not interchangeable. COUNT tells you how many rows match a condition — it counts occurrences. SUM adds up the numeric values in a specified column. If the question asks how many orders were placed, you want COUNT. If it asks for the total value of those orders, you want SUM. Read the question carefully and identify whether you are counting records or totalling a numerical field.


Mishandling strings and wildcards


Literal string values in SQL must be enclosed in quotation marks — writing WHERE Name = Smith instead of WHERE Name = 'Smith' is a syntax error. For pattern matching, the LIKE keyword is paired with the %wildcard, which represents any sequence of characters. WHERE Name LIKE 'S%' returns all names beginning with S. Using =instead of LIKE when pattern matching is required will not work as intended.


The single most effective way to improve at SQL is to write queries by hand, run them against a real or practice database, and read the output critically. Reading SQL is not the same as writing it. Put in the practice of constructing multi-table queries from scratch until the structure becomes automatic.


Tip 8: File handling has a clear structure — follow it every time


File handling questions are among the more mechanical parts of the paper, which makes the errors that appear in them particularly costly. The marks are not difficult — they reward students who have learned the correct structure and apply it consistently.

Three specific issues come up repeatedly.


Always close what you open.


Every OPENFILE statement must have a corresponding CLOSEFILE at the end of the operation. Leaving a file open is not a minor stylistic omission — it is a logical error, and it will lose marks. The habit to build is simple: the moment you write OPENFILE, write CLOSEFILE on the next available line, then fill in the operations in between. This way it is structurally impossible to forget.


EOF() requires the filename inside the brackets.


The EOF function checks whether the end of a file has been reached, and it needs to know which file to check. Writing EOF() with nothing inside is incomplete and incorrect. The file identifier — whatever variable or name you used when opening the file — must appear inside the brackets: EOF(MyFile). This is a detail that students frequently drop under time pressure, and it consistently costs marks.


Filenames passed as parameters are variables, not strings.


This is a subtle but important distinction. If a filename is passed into a subroutine as a parameter, it is a variable — it holds the name of the file as its value. Putting quotation marks around it turns it into a literal string, meaning the program would look for a file literally named whatever you typed, rather than using the value stored in the variable. If the parameter is called FileName, you write OPENFILE FileName — not OPENFILE "FileName". Reserve quotation marks for when you are directly specifying a filename as a fixed value in your code.


Tip 9: Show your working — all of it


Calculation questions in Computer Science are not just testing whether you get the right answer. They are testing whether you understand the process. An incorrect final answer with clear, correct working can still earn the majority of marks. A correct final answer with no working shown can earn very few. This asymmetry is important and worth taking seriously.


The specific errors that come up most often are these.


Binary arithmetic performed mentally without visible steps.


When adding or subtracting in binary, carry bits must be written out clearly above the relevant columns. An examiner cannot award method marks for carry operations they cannot see. Lay your binary arithmetic out column by column, write the carry row explicitly, and treat it with the same care you would give long division.


Unit conversion errors.


The most common version of this is forgetting to divide by 8 when converting from bits to bytes. A file size calculated in bits is not the same as a file size in bytes, and presenting one when the question asks for the other is incorrect regardless of whether the underlying arithmetic was right. Before writing your final answer, check the unit the question asks for and trace back through your calculation to confirm you have converted correctly.


Kibibytes, mebibytes, and the binary prefix system.


One kibibyte is 1024 bytes, not 1000. One mebibyte is 1024 kibibytes. These are not interchangeable with kilobytes and megabytes in an exam context. Read the question carefully to identify which prefix system is being used, and apply the correct conversion factor throughout.


The practice habit that fixes most of these issues is straightforward: narrate each step as you write it. If you cannot write a one-line explanation of what you are doing at each stage, that is a signal that the step needs more thought before it goes on the page.


Tip 10: The question stem is not the answer — add something new


This final mistake is worth addressing plainly, because it is one of the few errors that can result in a complete zero for a section of the paper despite the student having written several sentences.


Paraphrasing or restating information that the question has already given you does not earn marks. The examiner wrote that information into the question — they already know it. What they are awarding marks for is the technical knowledge you bring to it.


Here is a concrete example. The question describes a greenhouse system that turns off cooling fans when the temperature drops below a threshold, then asks you to explain how the system works. An answer that writes: "when the temperature is low, the cooling fans turn off" has added nothing — that is precisely what the question told you. An answer that earns marks explains the mechanism behind it: a temperature sensor continuously measures the air temperature and sends an analogue signal to an analogue-to-digital converter, which produces a digital value that the processor compares against a stored threshold. If the value falls below the threshold, the processor sends a signal via an output interface to the actuator controlling the fans, switching them off. That is the feedback loop. That is what the examiner is marking.


Before you write your answer, identify everything the question stem has already told you. Those facts are the starting point — your job is to explain the technical process that connects or underlies them. Every sentence in your answer should contain something the question did not already state.


If you find yourself writing a sentence and then recognising it from the question, stop, delete it, and replace it with the mechanism behind it.


Cambridge International A Level Computer Science student Full Q&A

Has the CIE A Level Computer Science (9618) syllabus changed for the 2027 examinations?


No significant changes. The 2027–2029 syllabus (Version 2, published December 2025) remains consistent with the curriculum introduced in 2021, so all textbooks and resources endorsed for the current 9618 syllabus are still fully applicable.


The Version 2 update included only minor administrative clarifications:

  • Calculator policy: Calculators are not permitted — students must demonstrate manual understanding of binary, hexadecimal, and mathematical logic.

  • Paper combinations: Wording was clarified on which papers are required for AS versus A Level entry.

  • Assessment objectives: The weighting for Knowledge (AO1), Application (AO2), and Design/Evaluation (AO3) remains unchanged across all papers.


Exam structure for 2027 (unchanged):

Paper

Type

Duration

A Level Weighting

Paper 1

Theory Fundamentals

1h 30m

25%

Paper 2

Fundamental Problem-solving & Programming

2h

25%

Paper 3

Advanced Theory

1h 30m

25%

Paper 4

Practical (Programming on computer)

2h 30m

25%

Each paper carries equal weight, making it important not to neglect any single component in your preparation.


When are the CIE A Level Computer Science (9618) exams held, and what are the key dates for 2027?


The 9618 exams are offered twice a year across two series:

  • June series — the main sitting for most international candidates, running from late April to early June. Paper 4 (Practical) is typically scheduled towards the end of this window as it requires a coordinated digital environment. Results are released in mid-August.

  • November series — suited for retakes or students on a different academic calendar, running from early October to mid-November. Results are released in mid-January 2028.


Key administrative deadlines:

Milestone

June 2027

November 2027

Final entry deadline

Mid-February 2027

Mid-August 2027

Late entry deadline

Mid-April 2027

Mid-September 2027

Exam period

April – June 2027

October – November 2027

Missing the final entry deadline means paying late fees, so flag these dates with your school or exam centre early.


What does it take to get an A* in CIE A Level Computer Science (9618), and how should you approach each paper?

The A* is only awarded at the full A Level — not for individual papers or AS Level alone. It's based on a weighted total out of 300 across all four papers.


Overall A* thresholds (recent data):

Series

Typical A* Boundary

Percentage

June 2025

228–240 / 300

~76–80%

November 2025

233–245 / 300

~78–82%

Historical average

~230 / 300

~77%


Targeting 240/300 (80%) is a reliable safe zone that holds up even in years where boundaries sit higher than usual.


Per-paper raw mark targets (each marked out of 75):


  • Paper 1 – Theory Fundamentals: 50–55/75

  • Paper 2 – Problem Solving & Programming: 50–55/75 (boundaries tend to be lower here as pseudocode trips up many students)

  • Paper 3 – Advanced Theory: 55–60/75

  • Paper 4 – Practical: 55–60/75


Can exam paper leaks cause CIE exams to be cancelled or prevent them from being taken?


No — Cambridge's position is effectively "the show must go on," prioritising students' university admissions timelines. However, leaks can cause delays and disruption. When a leak occurs, Cambridge typically responds in one of three ways:

  • Replacement paper: If the leak is caught before the exam, the compromised paper is withdrawn and a contingency "Series 2" paper is issued, sometimes with a short postponement of a few days to weeks.

  • Retake: If the leak is confirmed after the exam has already been sat, Cambridge may invalidate the original sitting and schedule a retake within the same series.

  • Assessed marks: In extreme cases where a retake isn't feasible, Cambridge may derive a mark from performance across other papers — though this is a last resort as it carries less weight with universities.


What this means for 2027


In response to the 2026 paper thefts — which Cambridge described as criminal — tighter security measures are likely to be in place, including trials of digital paper delivery in high-risk zones and stricter time-windowing rules to prevent papers from being shared across time zones.


The key practical takeaway is that even when leaks occur, Cambridge works to ensure the academic cycle concludes on time. Results release dates have remained unchanged despite disruptions, so university application deadlines are generally protected. Don't let leak-related news affect your preparation — focus on the content, not the headlines.

Recent Posts

See All
bottom of page