MATSEC AM Information Technology common mistakes
MATSEC AM Information Technology · Understand the traps and how to avoid them.
Writing a database design answer that lists table names and column names but never states primary keys, foreign keys, or the cardinality of each relationship, so the marker cannot tell whether the schema is normalised or even joinable.
Candidates treat the ER diagram or schema sketch as a drawing exercise and assume the examiner will infer the keys from the names; in practice AM past-paper mark schemes allocate explicit marks for key identification and relationship type, and students have often never seen a mark scheme.
What to do instead
Adopt a fixed written template for every schema answer: for each relation give the name, underline the primary key, list foreign keys with the relation they reference, and write relationship cardinality in words (one-to-many, many-to-many) plus the resolution table for any M:N. Practise on three past scenarios until the template is automatic, and self-mark against the key/cardinality marks you can identify.
Answering a 'describe the stages of the systems development life cycle' question with a memorised list of stage names only, with no statement of what is produced at each stage or why the stages are ordered that way.
Revision is often done by copying headings from notes, which feels like learning the topic; the candidate recognises the term and reproduces the label without ever having practised explaining inputs, outputs, or deliverables, which is where the marks sit.
What to do instead
For each SDLC stage write a three-line card: purpose, main activities, deliverable (for example feasibility study produces a feasibility report; design produces data-flow and schema specifications). Then answer one past question in full sentences and check that every stage named is followed by a deliverable and a reason for its position in the sequence.
Calculating a binary, hexadecimal, or two's complement conversion and writing only the final answer, with no working, then losing all marks when a single digit is wrong.
Candidates are used to calculator-style answers where only the result matters, and they rush because they believe number conversion is 'easy marks'; a slip in one place value then wipes out the whole item even though the method was sound.
What to do instead
Always show the place-value columns or the division-by-base remainders in a small table beside the answer. For negative numbers, state the sign bit and the invert-and-add-one step explicitly. Do two timed conversion sets per week and mark method marks separately from answer marks so the habit of showing working is reinforced.
Explaining a logic gate or circuit question by describing what the gates 'do' in general terms instead of constructing the truth table and deriving the Boolean expression from it.
Students memorise gate symbols and single-gate truth tables but never practise combining them; under time pressure they write prose because it feels faster than drawing a table, and prose cannot earn the intermediate marks the scheme awards for correct intermediate columns.
What to do instead
For every circuit question, draw the full truth table with one column per intermediate gate output before the final column, then read the expression off the table and simplify. Work through at least five multi-gate circuits (including NAND-only and XOR constructions) so the column-by-column method becomes the default response.
Describing a network topology or the OSI/TCP-IP layers by naming the layers or devices only, without saying what each layer or device actually does, what addressing it uses, or which device operates at which layer.
Layer names and device names are highly memorable labels, so revision stops at recognition; candidates do not connect the model to concrete behaviour such as encapsulation, MAC versus IP addressing, or why a switch does not need an IP address to forward frames.
What to do instead
Build a one-page matrix: layer, protocol data unit, addressing scheme, example protocols, and devices operating there. Then answer past questions by writing one sentence per layer covering function and addressing. Test yourself by explaining, without notes, why a router and a switch behave differently for a broadcast frame.
Treating a spreadsheet or database practical task as a formula-recall test, writing a formula that works for the sample row but does not use absolute references, and failing to check it copies correctly down the column.
Candidates test a formula only in the cell where they typed it, and the sample data often makes a relative reference look correct; the error only appears when the formula is replicated, which the exam requires but the candidate never simulates.
What to do instead
Before moving on, copy the formula down at least three rows and inspect the referenced cells. Decide deliberately whether each reference should be absolute ($A$1), mixed, or relative, and state the choice. Rehearse with VLOOKUP, IF, COUNTIF, and nested IF tasks where the lookup table must be locked, and check for #REF! and #N/A errors.
Answering an ethics, security, or data-protection question with a single generic sentence such as 'it is illegal' or 'use a strong password', rather than naming the specific measure, the threat it addresses, and the consequence of not applying it.
These topics invite moralising rather than technical description, and candidates have often revised the headline only; they do not realise that marks are awarded per distinct, correctly applied measure rather than for a general stance.
What to do instead
Prepare a threat-measure-consequence table for the syllabus areas (phishing, malware, unauthorised access, data loss, misuse of personal data). For each, list three concrete controls (for example two-factor authentication, encryption at rest, access logs) and the risk each reduces. In answers, name the control, say what it prevents, and add one sentence on the legal or operational consequence.
Ignoring the mark allocation and command word, so a six-mark 'discuss' question receives a two-line 'state' answer while a two-mark 'state' question receives a long essay that consumes time needed elsewhere.
Candidates read the topic, feel confident, and start writing whatever they know; they do not decode command words (state, describe, explain, discuss, evaluate) or use the mark tariff to budget sentences, so depth is mismatched to demand across the whole paper.
What to do instead
Before writing, underline the command word and the mark tariff and jot the number of distinct points required (roughly one point per mark). For 'discuss' and 'evaluate', plan a two-sided structure with a judgement. Practise by rewriting three of your own answers to match the tariff exactly, then time a full paper with this planning step built in.
Leaving practical evidence incomplete: a printout or screenshot of a spreadsheet or database solution with no formulas visible, no field definitions, and no test data showing expected versus actual results.
Candidates treat the practical component as 'finish the file' and submit the output screen, forgetting that the assessor must verify method, not just the final value; they also underestimate how much of the practical mark depends on documented testing and annotation.
What to do instead
Use a submission checklist: show formulas in a dedicated view or column, include the design view of tables with data types and keys, include a test plan table (test, data used, expected result, actual result, correction made), and annotate each screenshot with a caption explaining what it demonstrates. Run the checklist against one complete practice task before the exam.
Defining key terms by restating the word in the definition (for example 'a compiler compiles code' or 'validation validates data') instead of giving the distinguishing criterion that separates it from the nearest similar term.
Candidates revise by matching terms to short glosses and never contrast pairs, so under pressure they produce a circular sentence; they do not realise the marker needs the discriminating feature (compiler versus interpreter, validation versus verification) to award the mark.
What to do instead
For each term, write a definition as 'X is ... which differs from Y because ...'. Build contrast pairs across the syllabus (compiler/interpreter, validation/verification, LAN/WAN, primary/secondary storage, batch/real-time processing) and test yourself by defining each without using the term itself or its root.