GCE A/L Information & Communication Technology common mistakes
GCE A/L Information & Communication Technology · Understand the traps and how to avoid them.
When converting between binary, octal, decimal and hexadecimal, candidates convert the integer part correctly but drop or misplace the fractional part, or treat a fractional binary like 0.101 as if the digits after the point were ordinary place values (for example reading it as 101).
Most textbook drills use whole numbers, so positional weighting to the right of the point (2^-1, 2^-2, 2^-3) is rarely practised. Candidates also apply the repeated-division method to the fraction, when fractions require repeated multiplication by the target base.
What to do instead
Always split the number at the radix point and process each side with its own method: integers by repeated division by the target base reading remainders upward, fractions by repeated multiplication by the target base reading the integer parts downward. Verify by converting back, and memorise the weights 1/2, 1/4, 1/8, 1/16 so 0.101 can be checked as 0.5 + 0.125 = 0.625.
Candidates build a truth table for a multi-input circuit but fill rows in an arbitrary order, omit rows, or write the output column without first deriving intermediate signals, so a correct-looking final column is wrong for several input combinations.
Under time pressure, candidates jump straight to the output and try to reason the whole circuit in their head. With three or four inputs there are 8 or 16 rows, and errors compound silently because nothing is checked against the intermediate nodes.
What to do instead
Adopt a fixed routine: list inputs in strict binary counting order (000, 001, 010...), add one labelled column per gate output in signal-flow order (left to right), and fill each column completely before moving on. Then read the final column and, where asked, write the Boolean expression from the 1-rows using minterms and simplify with Karnaugh map or De Morgan's laws, checking the simplified form against the table.
When asked to design or critique a relational schema, candidates store multiple values in one field (for example a single 'phone' column holding three numbers, or a comma-separated list of subjects), or repeat the same data across many rows, and then cannot explain why an update anomaly occurs.
Candidates model the form they see on paper rather than the entities and relationships. Normalisation is memorised as definitions of 1NF, 2NF and 3NF without the skill of spotting repeating groups and partial dependencies in a concrete table.
What to do instead
Practise the discipline of listing entities, their attributes and the cardinality of relationships before writing any table. Then test each table against the normal forms by asking: does any cell hold more than one value (violates 1NF); does a non-key attribute depend on only part of a composite key (violates 2NF); does a non-key attribute depend on another non-key attribute (violates 3NF). Be able to state the specific anomaly (insert, update, delete) each violation causes.
In SQL questions, candidates mix up WHERE and HAVING, use COUNT(*) when they mean COUNT of distinct values, or write a GROUP BY query that selects a non-aggregated column not present in the GROUP BY clause, then present it as valid.
Aggregate queries are taught as syntax patterns rather than as a logical order of operations, so the distinction between filtering rows before grouping and filtering groups after grouping is not internalised.
What to do instead
Learn the evaluation order FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY and apply it explicitly to the question. Use WHERE for conditions on individual rows, HAVING for conditions on aggregate results such as COUNT or SUM. When selecting a column alongside an aggregate, ensure the column appears in GROUP BY, and use COUNT(DISTINCT column) when duplicates must not be counted.
Candidates describe the layers of a network model or the role of a device by name-dropping (for example 'the router works at layer 3') without explaining what the device actually does with the data, or they place a switch at the wrong layer or confuse a MAC address with an IP address.
Revision lists encourage memorising layer numbers and device names as isolated facts. Examiners' questions usually ask for a comparison or a justification, which requires understanding what information each device reads and forwards.
What to do instead
For every device and protocol, be able to answer three questions: what unit of data does it handle (frame, packet, segment), what addressing does it read (MAC, IP, port), and what decision does it make (forward within a LAN, route between networks, deliver to an application). Practise short comparison answers such as hub versus switch versus router, and TCP versus UDP, each with a concrete consequence.
In algorithm questions, candidates trace a loop by writing only the final output, skip an iteration, or fail to show how a variable changes, and when asked for the output of a nested loop or a search they give the wrong count or the wrong terminating value.
Candidates run the algorithm mentally instead of on paper, and off-by-one errors at loop boundaries (whether the condition is < or <=) are invisible without a trace table.
What to do instead
Always draw a trace table with one column per variable and one row per iteration, including the iteration that fails the loop condition. For searches and sorts, state the value of the key variables at each step. Check boundary cases explicitly: first element, last element, empty list, and a value not present.
When asked to distinguish a stack from a queue, or to choose a data structure for a scenario, candidates give the abstract definition but cannot apply it, for example using a stack to model a print spooler or a queue to model function calls, or they describe an array as a linked list.
Data structures are learned as definitions rather than as tools for problems, so the link between the structure's access rule (LIFO, FIFO, index access) and the real-world requirement is never made.
What to do instead
For each structure, memorise one canonical scenario and one operation cost: stack for undo, recursion and expression evaluation (push and pop at one end); queue for print jobs, buffers and scheduling (enqueue at rear, dequeue at front); array for fixed-size indexed access; linked list for frequent insertion and deletion. In exam answers, name the structure, state its access rule, then justify it against the scenario in one sentence.
In system analysis questions, candidates label a data flow diagram with processes that are really data stores or external entities, draw a context diagram containing internal processes, or produce a use case description that lists screens rather than actor goals.
The symbols of structured analysis look similar and candidates copy the shapes without applying the definitions. Requirements are often confused with design, so a candidate writes 'the system shall have a blue login button' where a functional requirement is expected.
What to do instead
Apply the test questions: an external entity is outside the system boundary and exchanges data with it; a process transforms data and must have a verb-noun name; a data store holds data at rest; a data flow is a named piece of data in motion. A level-0 context diagram shows exactly one process representing the whole system. Write requirements as testable statements of what the system must do or how well, keeping design decisions out.
On security questions, candidates recommend a single control (usually 'use a strong password' or 'install antivirus') for every threat, or they confuse authentication with authorisation, encryption with hashing, and a virus with a worm or Trojan.
Security is revised as a list of threats and a list of controls with no mapping between them, and the vocabulary of related but distinct concepts is learned by association rather than by definition.
What to do instead
Build a threat-to-control table: for each threat (phishing, malware, brute force, SQL injection, man-in-the-middle, insider misuse) state the vulnerability it exploits and at least two layered controls (technical, procedural, physical). Fix the definitions: authentication proves identity, authorisation grants permissions; encryption is reversible with a key, hashing is one-way; a virus needs a host and user action, a worm self-propagates across networks, a Trojan disguises itself as legitimate software.
When discussing cloud computing, mobile technology, IoT, AI or big data, candidates give only advantages and buzzwords ('cloud is scalable and cheap') without naming the service or deployment model, or without stating a limitation, risk or trade-off relevant to the scenario.
These topics appear in recent-syllabus questions and are often revised from marketing material. Candidates lack a framework for classifying a scenario, so answers stay generic and miss the marks awarded for application.
What to do instead
For each trend, prepare a compact framework. Cloud: IaaS, PaaS and SaaS, plus public, private and hybrid deployment, with risks such as vendor lock-in, data sovereignty, dependency on connectivity and ongoing cost. IoT: sensors, connectivity, processing and actuation, with risks of insecure default credentials and unpatched devices. AI and big data: the volume, velocity and variety of data, the need for training data quality, and issues of bias, privacy and accountability. In every answer, name the specific model or component, apply it to the scenario, then state one benefit and one risk.