MATSEC AM Computing common mistakes
MATSEC AM Computing · Understand the traps and how to avoid them.
Writing that cache is 'faster RAM' or 'extra memory the CPU uses' instead of explaining it as a small, fast SRAM store holding recently used instructions/data to exploit locality of reference.
Candidates memorise the hierarchy diagram and the slogan 'cache is faster' without learning why locality makes caching work, so they describe cache by speed alone and cannot distinguish it from virtual memory or buffers.
What to do instead
For every level of the memory hierarchy state four things: typical technology (registers, SRAM cache, DRAM main memory, magnetic/SSD secondary store), relative speed, relative cost per byte, and volatility. Then explain the locality principle: temporal locality (a reused item stays in cache) and spatial locality (nearby addresses are fetched in a whole cache line). Practise explaining why a loop summing an array runs faster than one chasing random pointers.
Describing interrupt handling as 'the CPU stops and runs the interrupt code', omitting the save of the current program counter and register state, the use of an interrupt vector, the switch to kernel mode, and the return via an RTI/IRET instruction.
Textbook summaries compress the sequence into one sentence, and candidates never trace what happens to the fetch-decode-execute cycle when an interrupt arrives mid-instruction.
What to do instead
Write the sequence as numbered steps: finish current instruction, save PC and status flags on the stack, look up the handler address from the interrupt vector table, switch to supervisor mode, run the handler, restore state and return. Then answer a follow-up: why interrupts are checked between instructions, not mid-instruction, and what 'maskable' versus 'non-maskable' means.
Writing code that works for the sample input but crashes or gives wrong answers on empty input, a single element, or the maximum size - for example a loop that reads one element past the end of an array, or recursion with no base case for n = 0.
Candidates test with the friendly example given in the question and stop; they do not habitually derive boundary cases before writing the loop condition.
What to do instead
Before coding, list the boundary cases in the answer booklet (empty, one item, all-equal, maximum size, negative values) and state the expected result for each. After coding, dry-run the empty case line by line. Make the loop invariant explicit in a comment so off-by-one errors become visible.
Producing pseudocode or Python that mixes paradigms incoherently - for example a class with public attributes and no constructor validation, or a 'recursive' function that also uses a global accumulator, so the stated design rationale no longer matches the code.
Candidates learn syntax for procedures, objects and recursion separately and never practise choosing between them under exam pressure, so they bolt features together to look sophisticated.
What to do instead
Before writing, write one sentence naming the paradigm and why it fits (e.g. 'a class because each account holds state and behaviour together'). Keep the code consistent with that sentence. When asked to compare approaches, give a concrete criterion - encapsulation, code reuse, ease of testing - and apply it to the actual problem, not in the abstract.
Drawing an ER diagram with a relationship line between two entities but no cardinality, or writing '1:1' where the scenario implies '1:M', and then carrying that error into the normalisation answer.
Candidates read the scenario sentence by sentence and convert each noun into an entity without asking 'one of these relates to how many of those?' for every relationship.
What to do instead
For each relationship, write the two sentences aloud: 'One customer places many orders' and 'One order is placed by exactly one customer'. Mark the crow's foot or 1/M on the correct end. Then check every foreign key in the relational schema matches the cardinality you drew.
Claiming a table is in third normal form because 'there are no repeating groups' - confusing 1NF with 3NF - or leaving a transitive dependency (e.g. studentID → courseID → courseName) in place while declaring 3NF achieved.
The definitions are learned as a list of slogans and candidates cannot spot a transitive dependency in their own table because they never test each non-key attribute against each candidate key.
What to do instead
Apply a checklist in order: 1NF - atomic values, no repeating groups; 2NF - no partial dependency on part of a composite key; 3NF - every non-key attribute depends on the key, the whole key and nothing but the key. For each non-key attribute write 'X depends on Y' and check Y is a candidate key. Show the decomposition and name the resulting tables.
Describing TCP as 'reliable and fast' and UDP as 'unreliable', without saying what reliability actually means (sequence numbers, acknowledgements, retransmission, ordering) or giving a justified use case for UDP such as live video or DNS.
Candidates memorise a two-row comparison table and cannot explain mechanism, so they cannot answer 'why would a game use UDP?' beyond 'it is faster'.
What to do instead
For each protocol state the mechanism, not the adjective: TCP uses a three-way handshake, sequence and acknowledgement numbers, retransmission on timeout, flow control and congestion control; UDP has a minimal 8-byte header and no connection state. Then justify one application per protocol by naming the requirement it meets (ordering vs low latency).
Computing a subnet mask or host range by pattern-matching a memorised table, then giving a broadcast address that is actually a usable host, or forgetting to subtract two from the host count for the network and broadcast addresses.
Candidates learn '/24 = 255.255.255.0' as a fact rather than deriving it from the number of network bits, so any prefix outside the common ones defeats them.
What to do instead
Always show the working: write the prefix as a binary mask, convert to dotted decimal, AND it with the IP to get the network address, set all host bits to 1 for broadcast, and state usable hosts = 2^(host bits) − 2. Check the answer by confirming the network and broadcast addresses are not inside the usable range.
Answering a security question by naming a control ('use a firewall', 'use encryption') without saying what threat it mitigates, where it sits, or what it does not protect against.
Candidates revise lists of technologies and defences separately from threat models, so they cannot connect a control to the attack it stops.
What to do instead
Use a threat–control–limitation sentence for every answer: 'A WAF filters malicious HTTP requests, mitigating SQL injection and XSS at the application layer, but it does not stop an attacker with valid credentials.' Classify the threat first (interception, modification, fabrication, interruption), then choose the control.
Treating an ethical scenario as a legal question, writing 'it is legal so it is acceptable', or giving a one-sided answer that ignores the stakeholders who are harmed.
Candidates look for a single right answer and are uncomfortable with trade-offs, so they collapse the analysis into legality or into personal opinion.
What to do instead
Structure every scenario answer: identify the stakeholders and what each stands to gain or lose; state the relevant principle (consent, transparency, data minimisation, fairness, professional duty); apply it to the facts; then give a recommendation plus the strongest counter-argument and why you reject it. Note explicitly where law and ethics diverge.