How G3 Computing Paper 2 Practical Works | SEC Examination Preparation

G3 Computing Paper 2 is the practical, computer-based assessment in the 2027 Singapore-Cambridge Secondary Education Certificate. Candidates use Python, JupyterLab and spreadsheet software to solve unfamiliar problems, test outputs and submit saved digital files. It is not a coursework project that can be finished at home.

The official K349 Paper 2 lasts two hours thirty minutes, carries seventy raw marks and contributes forty percent of the subject grade. It contains one compulsory spreadsheet question and four to five compulsory programming questions. Students must allow time to save the required softcopies within the examination.

Subject: SEC 2027 G3 Computing K349 (former code 7155)
Written Paper 1: 2 hours, 80 marks, 60%
Lab Paper 2: 2h30, 70 marks, 40%
Paper 2 tasks: one Spreadsheet question; four to five Python Programming questions
Centre software: spreadsheet, Python, JupyterLab; a Python quick reference is provided
Submission: softcopy files, with saving included in the allotted time

Source: SEAB G3 Computing 2027 K349 syllabus (assessment on pages 3–5; programming and spreadsheets from pages 7–11) and the 2027 SEC G3 official directory. This independent guide includes original Python and spreadsheet examples, not predictions of the actual examination questions.

Official 2027 K349 Paper 2 Assessment Format

The SEC Computing assessment requires both the written and lab-based papers. Paper 2 assesses only Module 2 Algorithms and Programming and Module 3 Spreadsheets; Paper 1 covers all five modules, including Computer Fundamentals, Networking and Impact of Computing. The real lab exam requires submitted outputs, not just a description of a proposed method.

One compulsory spreadsheet question.
Four or five compulsory Python programming questions.
Total seventy marks over 150 minutes, accounting for 40% of the final SEC Computing grade.
Each candidate uses a personal computer with spreadsheet and Python/JupyterLab access.
A Python quick-reference guide is provided; use it for syntax, not a substitute for algorithm design.
Files must be saved and submitted under examination instructions; saving time is within the 150 minutes.
Approved calculators may be used in both computing papers.

How G3 Computing Paper 2 Actually Works

Paper 2 is a lab examination, not a school coursework project

The 2027 G3 Computing K349 Paper 2 is a two-hour-thirty-minute supervised lab-based examination. Students work on a personal computer and submit required softcopy files. Unlike an extended coursework portfolio, its required work must be produced and saved under the examination’s own time conditions.

A candidate should prepare for the precise practical workflow: read an unfamiliar problem, interpret input and output requirements, make working files, test the result and save it properly before the allotted time expires. An elegant algorithm that is never correctly submitted may not meet the practical requirement.

One spreadsheet question and four to five programming questions

The official K349 assessment scheme specifies one spreadsheet question and four to five programming questions in Paper 2. The whole practical carries seventy raw marks and forty percent of the final grade, while the separate two-hour Paper 1 carries sixty percent.

This means a candidate cannot concentrate exclusively on Python while leaving spreadsheet skills undeveloped. Nor should a student allocate all lab time to a complicated formula and fail to attempt the remaining programming tasks. The paper assesses both Module 2 and Module 3.

Know the actual computer environment

SEAB specifies access to spreadsheet software, Python and JupyterLab, with each candidate having sole use of a personal computer. The centre is responsible for suitable computing facilities; the syllabus also supplies a Python quick-reference guide.

A practice routine should include starting, running and checking a Python program in the relevant environment, using a spreadsheet formula correctly, locating saved files and knowing how to produce the required file formats. Do not confuse local JupyterLab work with permission to access arbitrary internet services.

A saved file is an assessment output, not an administrative afterthought

The official duration includes time for saving the work on the candidate’s computer. Submitted softcopy files are the evidence examiners can mark; correct reasoning confined to an unsaved temporary screen is risky.

During school mocks, rehearse the permitted file naming, location and submission instructions issued by the invigilator. Save deliberately after meaningful changes and verify that the required file opens correctly. Do not invent a universal SEAB naming convention absent from the actual candidate instruction sheet.

Start programming with inputs and valid input conditions

Module 2 begins with problem analysis: distinguish the inputs the program needs from constraints that make an input valid. A number, a text field and a filename can be relevant in very different ways.

In a fictional school-event calculator, inputs might be the number of participants and a registration category. The student should say whether zero or a negative participant count is allowed before writing code. A program that computes an answer for invalid input may solve the wrong problem.

Specify output precisely before coding

The other part of problem analysis is identifying what counts as the correct output. Some tasks need one number; others need a list, formatted sentence or saved text file. A result with an incorrect label or wrong order may not fulfil the requirement even if the calculation is internally correct.

Write an example input-output pair from the stated conditions, then test code against it. Check units, rounding, ordering and punctuation if the task specifies them. Do not add explanatory messages to an output when the examination expects a precise data format.

Abstraction: ignore unnecessary story details

Computing problems are often embedded in realistic contexts. A task may mention a library building, student names and a weekend event, but the algorithm might only require a list of item quantities and a total. Abstraction retains the important details and removes distractions.

Underline the values, conditions and decisions the program actually uses. A long story does not imply a long program. An unnecessary detail should not create an extra variable or prompt just because it appears in the question.

Decomposition: split a task into testable parts

A program that reads data, validates it, classifies values and writes a result can be designed as separate smaller responsibilities. Decomposition helps the student locate mistakes and retest without repeatedly rewriting the whole solution.

Identify small tasks such as reading the file, parsing a record, applying a condition and generating output. Test each using controlled inputs. This does not mandate one function per line; sensible modularity fits the actual problem.

Sequence, selection and iteration: recognise what the task needs

The syllabus expects Python selection with if, elif and else and iteration with for and while. A repeated computation does not necessarily need a while loop, and a conditional requirement should not be implemented through unrelated repeated print statements.

Draw a short flowchart or verbal decision tree. Ask which statements always execute, which depend on a condition and which must repeat until a defined stopping point. This prevents infinite loops and incorrectly skipped branches.

Python input returns a string

Python’s input() function returns text. A student who immediately adds two inputs with the plus operator may concatenate them instead of producing an arithmetic sum. This is an important distinction between representation and intended type.

For example, textual ’12’ and ‘3’ combined as strings yield ‘123’. Correct numeric calculation requires appropriate conversion and input validation. A valid conversion for one test case does not guarantee that nonnumeric entries will be handled properly.

Use integers and floating-point values intentionally

Counts and index positions are often naturally represented as integers; measurements or averages may require floating-point values. The choice influences division, range construction and expected outputs.

Check whether a result can contain fractional values and what rounding is permitted. If twelve items are divided into groups of five, ordinary division and floor division answer different questions; neither should be chosen solely from habit.

Indexing and slicing: Python counts from zero

List and string indices in Python start at zero. The first item is at index zero, and many slices include their starting position while excluding their stop position. A student can mis-handle the last element even when the overall logic is sound.

Practise with a small original list such as [4, 7, 9]. Ask for index one and for a slice from one to three, then explain the result. Reusing an old example without explaining the boundary can conceal an off-by-one error.

Lists: choose between element and collection

A list stores ordered values and can be accessed, extended or processed in loops. Code that compares a whole list with an integer, or that treats a single list element like a nested list, can produce errors.

Before writing a loop, state what each iteration variable represents. In a list of marks, the loop variable might be one mark, while the original list remains the collection. Use meaningful identifiers to make this distinction visible.

Dictionaries: keys represent associations

A Python dictionary maps keys to values, which can model a student’s ID and selected activity, a category and price, or an item and quantity. Its use differs from retrieving the second value of a list by numeric position.

Ask how a given value should be located: by position in a sequence or by a meaningful key. When debugging a failed lookup, inspect whether the key exists rather than assuming it can be addressed with a position number.

Loops: prevent repeated and missed values

For and while loops are useful when an action must repeat, but the exit condition and iteration range matter. A loop that skips the last record or processes one item twice may still run without an error message.

Use a manual trace with a small collection of three records. Write the current index, value and accumulator after each step. Compare the intended count of processed items with the actual count before scaling up.

Functions: inputs, return values and scope

User-defined functions can accept parameters and return values, supporting modular solutions. Local variables have a different scope from global variables. An incorrect assumption about which value changes can lead to subtle logic failures.

Write the function’s job in one sentence, then test it with a few inputs independently of the whole program. Confirm what it returns and whether another part of the program receives the intended result.

File reading and writing: understand where data goes

The syllabus includes file input/output using open(), read(), readline(), write() and close(). A file’s contents are distinct from the filename itself, and an operation may create, append to or overwrite content depending on how the file is opened.

Use a safe scratch practice file under teacher instructions to learn each intended action. In examination work, confirm input filenames and output instructions carefully; overwriting source data or saving to a different folder can undermine an otherwise correct program.

Errors: syntax, runtime and logic are different

A syntax error prevents code from being interpreted correctly. A runtime error appears during execution under certain conditions. A logic error can produce a plausible but wrong result without stopping execution. Each type calls for a different debugging method.

For syntax, examine the reported location and surrounding structure. For runtime problems, reproduce the relevant input and state. For logic, trace values against expected outputs. Treating all errors as typing problems misses the underlying reasoning.

Trace tables: prove what the code actually does

The syllabus explicitly expects trace tables and dry runs. A trace records variable values after steps in a program, helping reveal incorrect branches, updates or loop conditions.

Use a table with iteration, current item, condition result and accumulator. If an average is wrong, show where the total or count first diverges from the expected value instead of merely changing the final print statement.

Boundary testing: normal values are not enough

The K349 outcomes include normal, error and boundary conditions. A program may work for a usual input but fail at zero, an empty list or the smallest allowable value. Those test cases are not optional extras when validation is part of the requirement.

If a score is permitted from zero through one hundred, test zero, one hundred and a value outside the range as well as a normal midpoint. State what response should happen for invalid data, following the problem’s conditions.

Validation: range, length, presence, format and existence

The syllabus names validation checks including range, length, presence, format, existence and check digit. They answer different questions. A nonempty string can still have an invalid numeric range, and a correctly shaped ID can still be absent from the data.

Identify the relevant invalid input condition before implementing a validation loop. Distinguish an interactive request to retry from a non-interactive file-processing rule requiring termination, where specified by the syllabus.

Min, max and average algorithms: understand the restriction

Algorithm design learning outcomes include obtaining minima, maxima, totals and averages without relying on built-in min(), max() or sum() functions when a question requires the underlying algorithm. A program that calls a forbidden shortcut has not demonstrated the intended reasoning.

Practise keeping the current best value or running total, updating it correctly and handling an empty collection if relevant. Afterwards compare the manual result with an allowed check in unassessed learning.

Search algorithms: distinguish value and location

A task can ask whether an item appears, where its first occurrence lies or the locations of every match. Those are not the same output. The syllabus includes searching without index() or find() when a method must be constructed.

Use a loop over the collection with an explicit position and decide whether to stop at the first match. If duplicate items matter, collect every matching position rather than returning only the first by habit.

String splitting and text processing

Splitting text based on whitespace or a given delimiter is a syllabus skill, including designing a split algorithm without the split() method where required. Inputs can contain repeated spaces, leading separators or empty fields.

State how the task defines the delimiter and expected empty pieces. Build a small test with two adjacent delimiters and check whether the algorithm creates the expected fields. A solution that works only for a perfect example is fragile.

Spreadsheet references: copying changes some addresses

A relative reference changes when copied, an absolute reference holds its position and a mixed reference holds either row or column. The formula must remain correct after being filled through a table, not merely work in its first cell.

For a fictional sales grid where each row quantity changes but a tax rate remains in a fixed cell, use a relative quantity reference and an absolute tax reference. Explain the purpose of the dollar signs rather than inserting them arbitrarily.

Spreadsheet IF and logical functions

The assessed spreadsheet skills include IF, AND, OR and NOT, among other functions. A formula can classify a row based on a condition and produce one value or another. However, it must handle the boundary correctly.

Write the intended rule in ordinary language first. If an age qualifies at sixteen or older, use a comparison that includes sixteen. A strictly greater-than sign would exclude the boundary even if the rest of the formula is valid.

Conditional SUM and counting: choose the correct set

SUMIF, AVERAGEIF and COUNTIF apply conditions to data. A candidate may use COUNT instead of COUNTIF and accidentally include every numeric value, or use COUNTA when the task asks for numbers only.

Identify which records meet the stated condition and compute a small expected result manually. Then use the suitable function, checking whether empty cells, text entries or exact category matches affect the count.

Lookup functions: exact match and approximate match differ

VLOOKUP, HLOOKUP, INDEX and MATCH are part of the specified spreadsheet functions. A lookup searching for an exact ID needs an exact match; approximate matching can return a different but apparently plausible record if the underlying table and arguments do not meet its assumptions.

State whether the task seeks a unique identifier or a range-based classification. For an exact ID, test both a known code and a missing code. For a range lookup, check sorting and boundary conditions as required by the chosen method.

Goal Seek: work backward from a target

Goal Seek finds the input that makes a dependent calculated cell attain a specified target. It differs from typing a desired output directly into a calculated cell, which would destroy the relationship the spreadsheet is supposed to model.

In a fictional budget, a target savings balance can lead to a required monthly contribution. Identify the variable that Goal Seek is allowed to change and the formula output that should reach the target. Verify the result afterward.

Conditional formatting is a rule, not manual colouring

Conditional Formatting automatically applies visual treatment according to rules. Manually colouring cells that currently satisfy a condition does not demonstrate the same skill because future changes would not update the formatting correctly.

Set a condition aligned with the question and test by changing a value in a practice copy. If a low balance should be highlighted below a threshold, ensure the boundary and reference are correct.

Dates and text processing in spreadsheets

The specified function list includes DAYS, TODAY, NOW, LEFT, MID, RIGHT, LEN, CONCAT, FIND and SEARCH. Students should understand which function returns a date difference, which extracts characters and which locates text, including case sensitivity where relevant.

Ask what output is required: number of days, a prefix, substring position or combined identifier. Test the formula with a short unfamiliar text value and check whether off-by-one positions or copied references change the result.

Data integrity and reproducibility matter

A solution may look convincing on its first row but fail after copying through twenty rows. A formula may contain hard-coded values that should refer to editable cells, or a Python function may work only for one familiar sample.

Test fresh rows and deliberately varied inputs. Ask whether changing one source value updates the dependent result properly and whether the student can explain the calculation. The practical exam rewards usable outputs, not screenshots of one attractive result.

Prioritise saving, testing and following the question

The two-hour-thirty-minute exam includes save time. Candidates must understand file paths and output requirements. Leaving the spreadsheet correct but the Python files incomplete, or vice versa, creates avoidable risk.

During school-supervised practice, use a checklist: all required questions attempted, each file exists, correct naming and location under the invigilator’s rules, programs tested and spreadsheet formulas extended as required. Do not assume a final rushed Save click is sufficient.

Paper 2 is closely linked to Paper 1 but not equivalent

Programming algorithms and spreadsheet reasoning appear in both the written and practical assessment. Paper 1 also covers Computing Fundamentals, Networking and Impact of Computing. The practical focuses only on Modules 2 and 3 and requires actual software output.

Explain the same algorithm in a dry run and then implement it on a computer. A student who understands the theory but cannot debug an execution should receive practical skill training; one who can copy code but cannot reason about it needs conceptual work.

Original Worked Example: School Club Spreadsheet and Python

Consider an original, fictional K349 Paper 2-style scenario: a school club maintains a list of participant codes and contributions for a charitable book exchange. The candidate is asked to calculate totals in a spreadsheet and process a separate list of attendance counts in Python. This is not an actual SEAB examination question.

Begin with the spreadsheet. Suppose a hypothetical table has a quantity in B2, a price in C2 and a fixed fee rate in H1. A calculated cost in D2 could use =B2*C2*(1+$H$1), provided the context requires applying that rate to the row’s subtotal.

When the formula is copied to D3, the quantity and price should change to B3 and C3, while the fixed rate remains H1. This is why $H$1 is an absolute reference. A student who uses H1 without dollar signs may obtain an incorrect rate after copying, even if D2 initially looked correct.

Now imagine a fictional classification rule: participants with a recorded count of at least five are labelled ‘Active’. A spreadsheet IF formula might be =IF(E2>=5,”Active”,”Other”). The test value five must be included. The code is an original example, and the actual exam may specify different categories or outputs.

To verify the rule, test counts of zero, four, five and six. The expected labels are Other, Other, Active and Active. Testing only six hides the possibility of using >5 instead of >=5, which is an ordinary boundary error.

For the Python part, imagine the program receives the list [4, 7, 5, 0, 8] and must calculate the total and count values at least five without relying on the built-in sum(). A manual trace can track total after each item: 4, 11, 16, 16 and 24.

The qualifying values are seven, five and eight, so the number of qualifying values is three. A student who treats the condition as strictly greater than five would count only two. The issue is understanding the requirement and loop condition, not code formatting.

One original learning implementation could begin with total = 0 and qualifying = 0, then loop through the list with for value in counts:, add each value to total, and add one to qualifying whenever value >= 5. Print or return exactly what the task asks.

Now try a smaller boundary input, [5]. A correct result is total five and qualifying count one. The empty list may demand a zero total and zero count or a different specified handling, depending on the question. A candidate must read the input constraints rather than assume.

Next suppose the task uses a text file with one count per line. The student must ensure the file is opened in the intended mode and that text is converted to numbers appropriately. The file contents should not be silently overwritten simply because another output file must be created.

A test case with an invalid line such as ‘five’ shows the difference between a normal calculation and validation behaviour. The task’s instructions should determine whether the program rejects the entire input file or takes another allowed action; the student should not invent a procedure that contradicts the specified requirement.

Finally, verify the spreadsheet and Python products separately. Changing the fee rate must update all relevant spreadsheet rows; changing the attendance values must change the Python calculation in the intended way. Save the completed required work in the format and place dictated by the school exam instructions.

This original scenario demonstrates why practical Computing preparation combines abstraction, formula references, algorithms, testing, boundaries, file management and evidence of a working solution. The real Paper 2 problems and exact submission names cannot be predicted from a practice example.

Our First-Principles SEC Computing Preparation Method

We adapt the teaching architecture of eduKateSG’s immutable Clementi small-group tutorial reference: diagnose the first unstable decision, explain its cause, model a small case, remove prompts, test transfer on unfamiliar input and retrieve the concept later. Computing makes this process observable in data, trace tables, code behaviour and reproducible results.

1. Diagnose the first error before rewriting everything

Read the task requirements and original file or script. Determine whether the first mismatch concerns an invalid input assumption, wrong spreadsheet reference, incorrect loop condition, file path or submission. A total mark alone does not show which principle the student needs.

2. Rebuild the concept on a very small case

For a list-processing problem, hand-trace only three values; for a copied spreadsheet formula, test two rows and a fixed reference. Explain why the correct behaviour follows from the requirement rather than telling the student to memorise another pattern.

3. Model one implementation and remove guidance

After teaching the principle, change the data and require a new program or formula without copying the first answer. A learner who can select the proper method independently shows more than familiarity with the original worksheet.

4. Separate syntax, logic, boundary and submission errors

Syntax problems need a language fix; logic errors require tracing and interpretation; boundary errors demand new tests; submission failures require file workflow rehearsal. These should not be collapsed into one vague label such as weak coding.

5. Introduce realistic lab conditions

As knowledge stabilises, rehearse on the authorised Python and spreadsheet software for 150 minutes, including saving and checking work. A perfect written algorithm that cannot be executed or saved under lab conditions is incomplete preparation.

6. Retrieve the same concept after a delay

A few days after correction, test the relevant rule using a new dataset or spreadsheet table. Do not show the original model first; record whether the student now handles the boundary or reference independently.

Paper-by-Paper Strategies

Before the clock begins: understand the lab instructions

Confirm the authorised computer environment, input files and task scope under the invigilator’s directions. The syllabus provides JupyterLab, Python, spreadsheet software and a Python reference; do not assume internet research or external coding assistance is permitted.

Spreadsheet task: design correct formulas and test copying

Build one correct formula, choose relative/absolute/mixed references deliberately, then fill and validate multiple rows. Check lookups, IF conditions, text/date operations, Goal Seek or formatting according to the actual task.

Programming tasks: analyse before typing

For each of four to five questions, identify input, output, validation and data structures. Use a simple correct algorithm and incremental tests instead of beginning with a large untested program.

Debugging: choose the remedy for the error type

Read syntax messages, reproduce runtime failures with relevant inputs and use trace tables for logic errors. Review normal, boundary and invalid cases, not only one easy sample.

Submission: verify softcopy outputs

Save files at meaningful checkpoints and check final filenames, folders and required formats under the centre’s instructions. The exam includes saving time but does not guarantee a recovery from an unsaved or overwritten output.

Time: avoid a single-task trap

Paper 2 includes a spreadsheet question and several programming questions. Use a progress check during practice and reserve time to run every required program and verify the final saved files.

Privacy and good computing practice

Use only authorised fictional or school-supplied data. Don’t expose personal information in code examples, uploaded files or screenshots. The syllabus’s wider Computing objectives treat security and privacy seriously.

A 90-Minute Focused Computing Tutorial

10 minutes: retrieve a data-type, reference or testing rule without notes.
15 minutes: examine an original wrong program or formula and find the first incorrect decision.
20 minutes: model a small Python trace or spreadsheet reference correction.
20 minutes: require a fresh independent task using changed inputs or copied formulas.
15 minutes: practise tests, boundary checks, and correct file-saving behaviour.
10 minutes: record the corrected principle and plan a delayed independent retest.

A small group with three learners can make each person’s reasoning visible. The lesson must use genuine student code and appropriate software; it is not permission for a tutor or AI to substitute for a candidate’s work in the national examination.

Common Mistakes and Specific Repairs

Paper 2 is thought to be 60% of Computing

Repair: The written Paper 1 is 60%; the lab-based Paper 2 is 40%.

The spreadsheet task is skipped because the candidate prefers Python

Repair: Prepare both modules; one spreadsheet question is compulsory.

Only one or two programming problems are attempted

Repair: Prepare for four to five compulsory programming questions.

Copied formulas accidentally move the fixed tax or threshold cell

Repair: Use an appropriate absolute or mixed reference and test a later row.

A lookup uses approximate matching for an exact ID

Repair: Select the matching method that fits the requirement and test missing values.

A count formula includes the wrong cells

Repair: Distinguish COUNT, COUNTA, COUNTIF and other relevant functions.

The condition at the boundary is incorrect

Repair: Test equal-to, just-below and just-above cases.

The student adds two input strings as if they were numbers

Repair: Validate and convert types before arithmetic.

An off-by-one slice misses the last item

Repair: Trace zero-based indices and exclusive stop boundaries.

A while loop never updates its stopping condition

Repair: Trace iterations and test termination on a small input.

A function prints a result when the caller expects a returned value

Repair: Check the stated function contract and data flow.

The program works only for the happy-path sample

Repair: Design normal, boundary and invalid-input tests.

A code error is hidden by changing the expected answer

Repair: Fix the implementation or clarify the contract, not the truth of the test.

A source data file is overwritten by output

Repair: Check file modes, paths and the required distinct files.

Correct work is not correctly saved or submitted

Repair: Follow the invigilator’s save instructions and verify outputs before finishing.

The student assumes the Python reference guide will solve the algorithm

Repair: Use the guide for syntax while independently designing, testing and explaining logic.

Four-Week SEC Computing Lab Revision Cycle

This four-week plan supports students who have already completed substantial K349 learning. It does not replace a full Computing course or guarantee a result.

Week 1 — Diagnose the environment and core algorithm skills

Review the official Paper 2 format, run original short programs under school-approved software, practise typing and saving, and attempt a spreadsheet formula with copied references. Classify mistakes into conceptual, execution, testing and file management.

Week 2 — Build spreadsheets as reliable models

Work on absolute/mixed references, IF and conditional counts, lookups, text functions, dates, Goal Seek and conditional formatting. Verify behaviour after copying or changing data. Retest earlier errors using new rows.

Week 3 — Deepen Python programming and debugging

Practise lists, dictionaries, functions, input and output files, loops, searching, aggregation and validation. Use trace tables and boundary cases; implement a small original solution incrementally rather than copying a full script.

Week 4 — Rehearse the complete lab-based exam

Under authorised mock conditions, complete one spreadsheet and several Python tasks within 2h30, including saving softcopies. Check that each required file is present and its content can be reopened, then target any repeated errors in later short practice.

Frequently Asked Questions

What is the 2027 G3 Computing lab paper?

K349 Paper 2, a 2-hour-30-minute computer-based exam worth 70 marks and 40% of the Computing result.

How much is Paper 1?

Two hours, 80 marks and 60% of the result.

How many questions are there in Paper 2?

One spreadsheet task and four to five programming questions, all compulsory.

Which software is specified?

Spreadsheet software, Python and JupyterLab, with a computer for each candidate.

Is a Python reference provided?

Yes. The official syllabus says a quick reference guide will be supplied.

Do candidates submit printed code?

The syllabus specifies softcopies of required work for marking; follow the centre’s exact save instructions.

Are file-saving minutes included in the 2h30?

Yes. The allotted duration includes time to save required work.

Does the Paper 2 programming syllabus include dictionaries?

Yes. It includes dictionary insertion, lookup, query and deletion.

Are list and string indices zero-based?

Python uses zero-based indexing; students should be careful with slice-stop boundaries.

Can programs use built-in sum and max for every algorithm problem?

Not when the question requires the specified manual aggregation or comparison algorithm; read the method restriction.

What validation checks are in scope?

Range, length, presence, format, existence and check-digit calculations, among others named by SEAB.

Which spreadsheet lookups are examinable?

VLOOKUP, HLOOKUP, INDEX and MATCH are in the official function list.

Are Goal Seek and Conditional Formatting tested?

They are included in the syllabus’s spreadsheet program features.

What does a good debug routine look like?

Reproduce the error, trace the relevant variables, correct the first wrong decision, then retest normal and boundary inputs.

Does a program that runs always earn full marks?

No. It must produce the specified correct outputs under relevant conditions and be properly submitted.

Can students rely on external AI coding tools during the exam?

Do not assume external tools are permitted. The official environment is specified; follow examination and centre rules.

How should parents support practice?

Ask the learner to explain inputs, outputs, tests and corrections, and encourage realistic supervised lab mock exercises.

Official Sources and Related Guides

The Next Useful Study Step

Begin with one original spreadsheet file and one Python program the student previously attempted. Identify the earliest failed requirement, fix it on a small case, test new boundary values and verify the files can be saved and reopened. Then practise the full practical under school-approved computer exam conditions.

eduKateSG · Independent 2027 SEC educational guidance; not an official SEAB publication. No examination grade or specialised Computing tuition availability is guaranteed.