SEC G3 Computing Examinations | What to Do (SEAB K349): begin by confirming K349 and preparing for TWO very different compulsory papers. Paper 1 is a two-hour written exam worth 60%; Paper 2 is a two-hour-30-minute lab-based exam worth 40%, requiring a spreadsheet task and four or five programming tasks in Python/JupyterLab. Candidates must save and submit the correct digital files during the allotted time. Computing preparation should therefore include concepts, precise algorithms, testing, spreadsheet functions, practical file handling and responsible computing behaviour. Memorising Python syntax alone is not enough.
Quick answer for 2027: K349 replaces reference code 7155. Written Paper 1 is 80 marks and draws from all five modules: Computing Fundamentals, Algorithms and Programming, Spreadsheets, Networking, and Impact of Computing. It includes single- and multiple-answer MCQs, short answers, matching, cloze and structured questions. Paper 2 is 70 marks and requires one spreadsheet question and four to five programming questions; candidates use a computer with spreadsheet, Python and JupyterLab software. A Python quick reference is supplied, and time to save the required work is already included in the exam period. This article gives a detailed study plan, 30 common error fixes and an exam-day checklist.
- 2027 G3 Computing SEC code: K349. Historical O-Level reference code: 7155.
- Paper 1 Written: 2 hours, 80 marks, 60% of total; all questions compulsory.
- Paper 1 can include single/multiple-answer MCQs, matching, cloze, short-answer and structured tasks from all five modules.
- Paper 2 Lab-based: 2 hours 30 minutes, 70 marks, 40% of total; all tasks compulsory.
- Paper 2: one Spreadsheet question plus four to five Python programming questions.
- The exam centre provides computer access, spreadsheet software, Python and JupyterLab; candidates save and submit softcopies under official instructions.
- A Python quick-reference guide is supplied for Paper 2, and relevant formulae are provided for written tasks as specified.
- SEAB-approved calculators are permitted in Papers 1 and 2, subject to current rules.
- Theoretical module list: Computing Fundamentals; Algorithms and Programming; Spreadsheets; Networking; Impact of Computing.
- For the computer lab, the assigned examination environment, files, saving procedure and permitted tool use are controlled by the centre and SEAB.
SEAB: Official 2027 G3 Computing K349 syllabus and Python Quick Reference PDF
Why code K349 matters under Full Subject-Based Banding
The Singapore-Cambridge Secondary Education Certificate begins in 2027, and each subject’s G level is recorded within Full Subject-Based Banding. K349 is G3 Computing and not the G2 Computing K237 or G1 Computing K127 scheme. The former code 7155 may appear on old resources but does not replace current 2027 registration. School candidates should confirm the code through their school and later entry proof. The private-candidate SEAB list also sets specific arrangements for Computing; eligible candidates must use the current official conditions rather than assume every computer science syllabus is available to every candidate.
A useful first-principles approach starts by asking what an algorithm is meant to do, what inputs are valid, what the outputs must satisfy, and why the program works across different cases. Students who learn only to copy code often fail when the task changes. A stable solution requires decomposing the problem, choosing appropriate data structures, verifying boundary conditions and saving correct evidence of the result. The same discipline applies to spreadsheets: a formula is not reliable if it only gives the right value in the first row but breaks when copied.
The exact paper structure and where the marks come from
| Component | What is assessed | Duration | Raw marks | Weight |
| Paper 1 Written | All five modules; mixed MCQ, matching, cloze and structured questions | 2 hours | 80 | 60% |
| Paper 2 Lab — Spreadsheet | One practical spreadsheet question | Part of 2h 30m | Within 70 marks | Part of 40% |
| Paper 2 Lab — Python | Four to five compulsory programming questions | Same lab exam | Within 70 marks | Part of 40% |
The assessment objective split across the qualification is approximately 30% knowledge/understanding, 40% application and 30% design, development, testing and refinement. Paper 1 carries all 30% knowledge weighting alongside application and problem solving. The lab assesses application and hands-on design/test/refinement. This division means candidates should practise explaining why code behaves as it does in addition to writing programs that run correctly. There is no optional programming question to omit.
The five official modules and why each matters
- Module 1 Computing Fundamentals: architecture, memory, storage, binary/denary/hexadecimal, two’s complement, encoding and logic gates.
- Module 2 Algorithms and Programming: input-output requirements, flowcharts, Python variables, types, conditions, loops, strings, lists, dictionaries, functions, files, algorithm design, testing and debugging.
- Module 3 Spreadsheets: absolute/relative/mixed references, Goal Seek, conditional formatting, logical, mathematical, text, lookup, date and statistical functions.
- Module 4 Networking: LAN/WAN, topologies, protocols, packets, addresses, home networking, privacy and cybersecurity safeguards.
- Module 5 Impact of Computing: technology in society, intellectual property and licensing, online falsehoods, AI and emerging technologies.
Study the exact listed Python methods and spreadsheet functions in the official K349 PDF rather than guessing the whole modern language or every library is examinable. The Python quick reference in the syllabus defines the supported standard functions and tools; students should know when a task explicitly requires an algorithm WITHOUT a convenient built-in. For example, the syllabus tests finding a list maximum manually without calling min() or max(), and other common list, string or search operations without their shortcut methods.
Written Paper 1: read diagrams, code and consequences accurately
The written paper is not a multiple-choice-only test. Candidates may need to translate a logic circuit into a Boolean statement, perform a binary conversion, trace Python variable values, select an appropriate spreadsheet formula, explain a network or evaluate a computing-related social issue. When practising, require a reason for the answer. For numerical work, check the distinction between decimal kilobytes and binary kibibytes; for Python, check whether division creates a float and whether list indexing begins at zero; for networking, distinguish identity on a local network from addressing across networks.
A sensible examination routine is to scan question type, write down the required output or explanation, solve and then test against the command. For multi-answer MCQ tasks, do not automatically assume exactly one option is correct. For flowcharts, follow every branch and repeated step through a manual trace. For security questions, avoid claiming that one control stops all threats. A firewall, encryption, anti-malware and responsible human behaviour solve different parts of a protection problem.
Lab Paper 2: spreadsheet and Python workflows that actually work
In the lab, first inspect any provided files and the instructions for naming, saving and submission. For the spreadsheet task, verify data ranges, types, formula copying, lookup behaviour and display rules. For programming tasks, read each input-output specification, sketch a small algorithm, implement incrementally, test normal/boundary/invalid cases and verify the required output. Save the correct files in the designated location regularly, following the exam’s actual permitted process. The 2h30 period includes file-saving time, so a perfect program in an unsaved file is not a complete submission.
Use the examination centre’s authorised hardware and software. The official syllabus specifies access to spreadsheet software, Python and JupyterLab and states each candidate should have sole use of a computer. Do not assume personal internet access, third-party packages, AI coding tools or a preferred editor will be permitted. Practise basic JupyterLab workflow, but test code in a plain Python script context as needed so the solution’s logic is not dependent on remembered notebook state. The authorised instructions determine the actual environment.
Thirty high-impact K349 mistakes and how to repair them
1. Bits, bytes, KB and KiB confused
What goes wrong: Students apply a 1,000 factor to every memory conversion.
Corrective action: Read the unit carefully: metric and binary prefixes are different, then track powers.
Worked example: 1 KiB is 1,024 bytes; 1 kB is 1,000 bytes in the usual decimal prefix convention.
Independent retest: Convert the same capacity with both prefixes and explain the difference.
Why it matters: Units are part of computing accuracy.
2. RAM and secondary storage treated alike
What goes wrong: A computer’s volatile working memory is mistaken for persistent storage.
Corrective action: Distinguish processor, main memory and permanent storage functions.
Worked example: An unsaved program held only in a volatile working state can be lost after a restart.
Independent retest: Classify five hardware components by purpose.
Why it matters: System architecture determines behaviour.
3. Data bus and address bus conflated
What goes wrong: The learner says both buses carry exactly the same kind of information.
Corrective action: Explain address selection versus data transfer in a memory operation.
Worked example: A read must identify which location to access and then transfer its stored data.
Independent retest: Draw a simple CPU-memory data flow.
Why it matters: Precise component roles matter.
4. Binary positional values guessed
What goes wrong: A conversion works for small numbers but fails with more than four bits.
Corrective action: Use place values 1, 2, 4, 8 and so on; verify by reconstructing the decimal value.
Worked example: Binary 10110 equals 16 + 4 + 2 = 22.
Independent retest: Convert an unfamiliar number both directions.
Why it matters: A reversible calculation provides a natural check.
5. Hexadecimal digits misread
What goes wrong: The student treats hexadecimal A or F as decimal letters rather than values.
Corrective action: Use base-16 place value and correct digit mapping.
Worked example: Hexadecimal 1F equals 1×16 + 15 = 31 decimal.
Independent retest: Convert a byte to two hex digits and back.
Why it matters: Representation depends on radix.
6. Two’s complement width ignored
What goes wrong: A negative number is written without specifying bit width.
Corrective action: Fix the number of bits, perform the complement procedure and verify representable range.
Worked example: An 8-bit two’s-complement representation has a different range from a 4-bit one.
Independent retest: Encode and decode an example at a fixed width.
Why it matters: Bit width determines meaning.
7. Logic gate truth tables incomplete
What goes wrong: Some input combinations are omitted from a three-input circuit.
Corrective action: Enumerate all 2^n cases before evaluating gate outputs step by step.
Worked example: Three Boolean inputs produce eight combinations.
Independent retest: Complete one AND/OR/NOT composed circuit.
Why it matters: A full table prevents missed cases.
8. De Morgan’s law applied to only one term
What goes wrong: A negation is distributed without changing AND to OR or vice versa.
Corrective action: Write the full law and test two input combinations.
Worked example: NOT(A AND B) equals (NOT A) OR (NOT B).
Independent retest: Use a truth table to verify the transformed expression.
Why it matters: Logical equivalence can be proved.
9. Inputs and outputs never specified
What goes wrong: Coding starts before the required valid inputs and desired outputs are clear.
Corrective action: State input constraints, output format and examples before choosing algorithm.
Worked example: A program averaging scores must define how empty input is handled.
Independent retest: Write three test cases before the first line of code.
Why it matters: Specification drives implementation.
10. Python input() treated as number
What goes wrong: The program attempts arithmetic on a string returned by keyboard input.
Corrective action: Convert and validate the value before numeric operations.
Worked example: Text ‘5’ plus text ‘2’ concatenates; numeric 5 + 2 gives 7.
Independent retest: Test the same prompt with valid and invalid input.
Why it matters: Types determine operations.
11. Integer division, float division and modulo confused
What goes wrong: The learner assumes /, // and % return the same kind of result.
Corrective action: Identify quotient, floor quotient and remainder according to Python semantics.
Worked example: 7 / 2 gives 3.5, 7 // 2 gives 3, and 7 % 2 gives 1.
Independent retest: Use positive values then test a negative case.
Why it matters: Operators have distinct contracts.
12. Off-by-one list indexing
What goes wrong: A student assumes the first element is at index 1.
Corrective action: Use zero-based positions and verify length before indexing.
Worked example: For items [10,20,30], items[0] is 10 and items[2] is 30.
Independent retest: Trace a loop over a three-element list.
Why it matters: Boundary indices cause common runtime errors.
13. Slicing endpoint misunderstood
What goes wrong: A substring is extracted with one extra or missing character.
Corrective action: Recall that Python’s slice stop index is excluded.
Worked example: ‘ABCDE'[1:4] is ‘BCD’, not ‘BCDE’.
Independent retest: Extract three intervals including empty slice.
Why it matters: Clear interval reasoning prevents string errors.
14. String versus list mutation confused
What goes wrong: The student attempts to change an immutable string character in place.
Corrective action: Choose an appropriate string-rebuilding or list operation for the task.
Worked example: A string slice produces a new string; it does not rewrite the original variable automatically.
Independent retest: Rewrite a character-replacement exercise and test output.
Why it matters: Data structure properties matter.
15. Dictionary key and value mixed
What goes wrong: A lookup uses a value as if it were a unique dictionary key.
Corrective action: Define keys and the relationship they represent before storing data.
Worked example: Student IDs can be keys mapping to details; duplicate human names are unreliable identifiers.
Independent retest: Write a simple dictionary insertion and lookup test.
Why it matters: A data model affects correctness.
16. Loop exits at wrong time
What goes wrong: The stopping condition is checked incorrectly or the control variable never changes.
Corrective action: Trace initial state, condition, body and update; test one and zero iterations.
Worked example: A while loop with an unchanged condition can continue indefinitely.
Independent retest: Use a trace table for five steps or until termination.
Why it matters: Termination is part of algorithm design.
17. Global state used instead of parameters
What goes wrong: Functions depend on hidden variables and fail when called with new inputs.
Corrective action: Pass needed values as parameters and return results when appropriate.
Worked example: A function that computes a mean should receive its list rather than read one secret global list.
Independent retest: Call the same function on two different lists.
Why it matters: Modular design improves testing.
18. Algorithm shortcut used when prohibited
What goes wrong: The student uses max(), sum() or find() where the task tests a manually designed algorithm.
Corrective action: Read the exact prompt and implement the required loop or search logic.
Worked example: Find a list maximum by initialising from the first element and comparing each remaining item.
Independent retest: Test with negative numbers and one-element lists.
Why it matters: A correct function call may not satisfy a restricted algorithm task.
19. Testing only ordinary values
What goes wrong: Code works for the middle of a range but fails at boundaries or invalid entries.
Corrective action: Design normal, boundary and error tests linked to the input specification.
Worked example: For allowed ages 13 to 16, test 13, 16, 12 and 17 as well as a typical mid-range case.
Independent retest: Record expected and observed outputs.
Why it matters: Tests should be chosen to reveal faults.
20. Validation and verification confused
What goes wrong: The user assumes a range check proves a value is factually correct.
Corrective action: Separate data meeting input rules from data matching an external truth.
Worked example: An entered date can be formatted correctly yet refer to the wrong event.
Independent retest: Describe one example requiring format validation and source verification.
Why it matters: A legal-looking value is not necessarily true.
21. Syntax error versus logic error
What goes wrong: A program that runs is assumed to be correct.
Corrective action: Check whether the program fails to parse, crashes, or returns the wrong result.
Worked example: A valid program averaging N values might divide by N−1 and still run.
Independent retest: Classify three defective snippets by error class.
Why it matters: Different faults require different debugging methods.
22. Print-debugging without hypothesis
What goes wrong: Dozens of print calls are added without tracing the first incorrect value.
Corrective action: Insert a targeted diagnostic at a meaningful boundary, then backtrack from the first wrong state.
Worked example: If a total becomes wrong after one loop iteration, inspect that iteration’s item and update.
Independent retest: Write a two-column expected/actual trace.
Why it matters: Debugging should isolate causes.
23. Spreadsheet relative reference breaks copying
What goes wrong: A tax rate reference moves down a row when a formula is filled.
Corrective action: Use absolute, mixed or relative references according to the intended copied pattern.
Worked example: =$B2*C$1 fixes a different dimension from =B2*C1.
Independent retest: Copy a formula through two rows and columns and inspect cell references.
Why it matters: Formula behaviour is structural, not visual.
24. Spreadsheet Goal Seek misused
What goes wrong: The feature is treated as a replacement for a correctly linked calculation.
Corrective action: Set the objective cell, target value and changing input only after formulas are valid.
Worked example: A profit model can solve for sales quantity, but not if profit is a hardcoded number.
Independent retest: Test the result by substituting it back into the sheet.
Why it matters: Spreadsheet automation needs a sound model.
25. Lookup wrong matching mode
What goes wrong: An approximate lookup is used on an unsorted table or for unique identifiers.
Corrective action: Choose exact versus approximate matching deliberately and validate lookup ranges.
Worked example: Student IDs usually require exact matches; interval classifications can use a properly sorted range table.
Independent retest: Test a key at the boundary of two categories.
Why it matters: A silent wrong lookup may be harder to notice than an error.
26. Spreadsheet conditional formatting mistaken for data
What goes wrong: A coloured cell is assumed to contain the calculated result or validation logic.
Corrective action: Treat formatting as a display driven by data, not the source of the data.
Worked example: A red highlight can signal a low score but does not itself prove a formula is correct.
Independent retest: Change source data and check both formula and formatting.
Why it matters: Presentation is not a substitute for computation.
27. Networking MAC versus IP addresses
What goes wrong: The candidate uses MAC and IP as if their roles are identical.
Corrective action: Distinguish local-LAN hardware addressing from network-layer routing across networks.
Worked example: A switch and a router rely on different kinds of information when forwarding data.
Independent retest: Explain a packet’s journey through a home LAN and towards the internet.
Why it matters: Different network layers solve different problems.
28. Encryption, firewall and anti-malware conflated
What goes wrong: One security measure is claimed to block every threat.
Corrective action: Explain what each control protects and its limits.
Worked example: Encryption protects confidentiality of data; a firewall filters traffic using rules; anti-malware addresses malicious software.
Independent retest: Match controls to three distinct threats.
Why it matters: Defence is layered and contextual.
29. Phishing, pharming and cookies blurred
What goes wrong: The student calls every privacy risk a virus.
Corrective action: Differentiate deceptive messages, redirection attacks and tracking mechanisms.
Worked example: A phishing email asks for secrets using impersonation; cookies may have legitimate functions but can enable tracking.
Independent retest: Classify three safe hypothetical examples.
Why it matters: Correct terms support appropriate prevention.
30. Copyright and software licences ignored
What goes wrong: All free-to-download software is assumed to permit unrestricted redistribution.
Corrective action: Distinguish freeware, shareware, proprietary and open-source licences and the permissions they actually grant.
Worked example: An author allowing free use does not automatically permit copying or resale under all conditions.
Independent retest: Compare two fictional licence terms.
Why it matters: Computing ethics includes lawful reuse of work.
31. AI and online falsehoods analysed as slogans
What goes wrong: The student says AI is always good or harmful without considering data, bias and responsibilities.
Corrective action: Use a specific application, its benefit, limitation and stakeholder impact.
Worked example: An automatic recommendation system can improve relevance but also amplify misleading high-engagement claims.
Independent retest: Evaluate an illustrative tool using accuracy, privacy and transparency criteria.
Why it matters: Ethical analysis should be evidence-based.
32. Lab files not saved or named correctly
What goes wrong: The candidate solves tasks but submits wrong files, an old version or nothing.
Corrective action: Reserve time to follow the authorised naming, save and submission sequence and verify outputs.
Worked example: The 2h30 duration includes saving time; an unsaved notebook does not become a submitted answer.
Independent retest: Practise a full mock with a file inventory checklist.
Why it matters: Operational accuracy is part of completing the exam.
Worked algorithm example: finding the maximum without max()
Suppose a Paper 2 practice task provides the list [−8, −3, −11, −5] and asks for the maximum WITHOUT using Python’s max() function. A common error is to initialise the maximum to zero, which yields the incorrect result zero for an all-negative list. Instead, first handle the possible empty-list case according to the given specification. For a non-empty list, initialise the candidate maximum using the first element, then compare every remaining value and replace the candidate only when a larger value appears. The correct result here is −3. The method works for positive, zero, negative and mixed inputs.
Use a trace table with columns for the current item and current best value. This tests the algorithm without needing a machine or memorised code. For a separate assessment, write and run Python code, then verify with boundary and error cases. If the problem explicitly prohibits a built-in function, the educational purpose is understanding the generic steps rather than hiding the logic inside a library call. The practice task is original; the official 2027 question will set its own constraints.
Worked spreadsheet example: copied discount formula and lookup
Imagine a worksheet where B2:B20 contains prices and E1 contains a discount rate. A student writes =B2*(1-E1) in C2 and fills down. The formula is initially correct, but when copied to C3, E1 may move to E2, causing an incorrect rate to be used. If the intention is to keep the discount rate fixed, the rate reference should be absolute: =B2*(1-$E$1). The B2 price reference should remain relative because each row has its own price. Verify the result after filling, rather than trusting that all cells display reasonable-looking numbers.
Now consider a lookup of student IDs. When keys are identifiers, choose an exact-match lookup and appropriate table reference instead of an approximate-match mode that might silently return another person’s details. Always test an ID that exists and one that does not, and decide how a missing value should be handled under the question’s instructions. These spreadsheet decisions transfer to real budgeting, inventory and data analysis, not only examinations.
A secure lab-preparation workflow for Paper 2
During ordinary school-approved practice, create a test project with one spreadsheet and several small Python tasks. Open only the supplied files, read the output requirements, plan each part, implement and save under specified filenames. Then reopen the saved versions and verify that formulas, programs and outputs remain correct. Do not rely on notebook cells run in a strange order or unrecorded variables created in an earlier session. A good test of reproducibility is to restart a practice notebook and run the cells in the intended sequence with correct inputs.
At the actual examination, use only the software and workflow authorised by the examination centre. If hardware or the application malfunctions, immediately inform the invigilator rather than attempting unauthorised internet access or external tools. Do not download libraries or use AI assistants unless explicitly allowed in the current candidate instructions. The syllabus provides a Python quick-reference guide; learn to read it efficiently, but practise fundamental syntax and program logic independently beforehand.
How to spend twelve weeks preparing for Computing K349
Weeks 12–9: first-principles diagnostic
Map the five official modules and attempt one task each on number representations, a truth table, Python input-output and iteration, spreadsheet references and networking/ethics. Identify the first wrong reasoning step, not just the percentage. A learner who cannot trace a loop needs short manual trace-table practice before writing another 100-line program. A learner whose spreadsheet formulas fail after copying needs reference-behaviour exercises before advanced lookups. Repair foundational misconceptions early.
Weeks 8–5: alternate programs and spreadsheets
Interleave Python lists, strings, functions and testing with spreadsheet functions, conditional formatting and Goal Seek. Introduce mixed questions where the student first selects the right representation and method. Add one networking or computing-impact discussion each week so theoretical components do not disappear behind lab practice. After each error correction, use new input data. A memorised script that runs once is less useful than a small algorithm the student can adapt.
Weeks 4–2: full timed Paper 1 and Paper 2
Sit a two-hour written simulation across all five modules. Separately run a two-hour-30-minute lab mock containing a spreadsheet task and four or five programming exercises, with a genuine save-and-reopen step. Record which errors arose from logic, syntax, files, range references, data types, missing input validation or time. Where the school offers the official software environment, practise with the same type of tools and permitted settings. Do not improvise unofficial exam-system workarounds.
Final week: stable execution and administrative readiness
Revisit the error log, common spreadsheet formulas, the Python quick reference categories, boundary testing and a short network-security summary. Confirm K349, venue, reporting time, approved calculator and lab equipment instructions with the school or SEAB. Ensure the student understands the saving/submission procedure. Maintain rest; exhausted programmers are more likely to overlook an off-by-one index or forget to save a final edit.
A seven-day Computing revision cycle
| Day | Focus | Evidence of progress |
| Monday | Binary, logic and architecture | Accurate conversion and truth table |
| Tuesday | Python loops, lists and strings | One new algorithm with boundary tests |
| Wednesday | Spreadsheet functions and references | Formula copies correctly and lookup verified |
| Thursday | Networking and security | Correct packet/address/control explanation |
| Friday | Impact, ethics and data validation | Reasoned privacy or licensing response |
| Saturday | Timed Paper 1 or complete lab practice | All compulsory tasks and files completed |
| Sunday | Retest two repeated mistakes and rest | Correct independent solution on new data |
Frequently asked questions: SEC G3 Computing K349
What is the 2027 G3 Computing code?
K349, with historical reference code 7155.
How many compulsory papers are there?
Two, one written and one lab-based.
What is Paper 1’s duration and weight?
Two hours, 80 raw marks, 60% of the subject.
What is assessed in the written paper?
All five modules through MCQ, matching, cloze, short-answer and structured questions.
How long is Paper 2?
Two hours 30 minutes, 70 raw marks, 40%.
How many Paper 2 spreadsheet tasks are there?
One spreadsheet question.
How many programming questions are there?
Four to five Python programming questions in the lab-based paper.
Are any questions optional?
No. Both papers contain compulsory tasks.
What software is used in the lab?
The centre provides spreadsheet software, Python and JupyterLab under official arrangements.
Is a Python reference provided?
Yes. A quick-reference guide for Python is provided in Paper 2.
Are calculators permitted?
SEAB-approved calculators may be used in both papers, subject to the current rules.
Does saving count within the lab time?
Yes. The allotted 2h30 includes time for saving required work.
Is knowing Python alone sufficient?
No. The written paper includes fundamentals, spreadsheets, networking and computing’s impact.
Which spreadsheet functions are relevant?
The syllabus lists logical, lookup, statistical, mathematical, text and date functions, including exact and approximate lookups.
What is the difference between a syntax and logic error?
A syntax error prevents code from being parsed; a logic error can still run but give the wrong result.
What if the exam task prohibits a built-in function?
Follow the restriction and implement the required underlying algorithm explicitly.
Can I assume I can access the internet or AI coding tools?
No. Use only software and resources explicitly authorised by the centre and SEAB.
What if a computer malfunctions during the exam?
Inform the invigilator immediately and follow official technical-incident procedures.
Does K349 examine privacy and legal issues?
Yes. It covers security, personal data, licensing, intellectual property and online information.
Can older 7155 exercises help?
They can support aligned practice, but the official 2027 K349 syllabus controls current requirements.
Is G2 Computing K237 the same as K349?
No. The subject levels and examination formats differ.
What should parents ask after practice?
Which bug caused the wrong result, and can the student fix that type of bug on a new program?
Where are the latest official rules?
The SEAB 2027 K349 syllabus, subject list and the examination centre’s candidate notices.
Official SEAB sources and further eduKate reading
The 2027 K349 code, 60/40 paper weights, five-module scope and lab arrangements were checked against the official syllabus on 11 November 2026. Use the current official centre instructions for software, devices, saving, administrative matters and actual examination dates.
SEAB: 2027 SEC G3 subject codes and list
eduKate: K349 Python, JupyterLab and spreadsheet exam guide
eduKate: How Computing skills extend to A-Level and further study