How to get an A at AS and an A* in Cambridge A Level Information Technology

Read a practical task like a specification

Before working, mark the requested inputs, transformations, outputs and evidence. Make a small checklist you can follow during practice. A task may assess a working formula, a suitable data type or a correctly filtered report even when the final page looks visually simple.

At AS, build reliable habits for file organisation, naming and saving. Use the software your centre supports, and learn where to verify settings rather than memorising a sequence of clicks. A changed interface should not stop you from understanding the feature you need.

Treat data accuracy as part of design

For spreadsheet or database practice, check sample records manually before trusting the whole output. Ask whether a formula should use a relative or fixed reference, whether a field needs a particular data type, and whether a criterion includes the correct boundary. Format the result only after the calculation is correct.

When joining or filtering data, predict how many records should remain in a tiny test example. Unexpected duplication or missing records can reveal a mistaken relationship or condition. Use realistic but invented practice data; there is no need to expose classmates’ personal information to learn these skills.

Connect each recommendation to a user need

A useful theory answer names the organisation’s requirement, explains a relevant technology and weighs a limitation. Do not answer every security question with password or every backup question with cloud. Consider the data, the users, the consequences of failure and the practical constraints in the scenario.

At A2, develop longer comparisons and integrated solutions. Explain how parts of a system work together and what can go wrong at their boundaries. A technically impressive feature has little value if it prevents the intended user from completing the task reliably.

Make evidence and testing routine

During timed practice, reserve a final check for requirements, saved files and requested evidence. Screenshots or outputs should show the actual feature being assessed. If a formula is required, an image of a final number may not demonstrate how it was produced; follow the task’s evidence instructions precisely.

After marking your work, classify the failure: misunderstood brief, incorrect feature, inaccurate output, missing evidence, or time management. Rebuild the weak part from a blank file. This is more useful than decorating a completed document that already meets the visual requirements.

Common mistakes—and how to fix them

Your four-week revision plan

Use this as a focused revision cycle alongside your lessons. If you are still learning the course, give unfamiliar topics more time before attempting full papers.

1. Week 1

   Audit practical workflows

   • Confirm software and technical guidance.
   • Build short tasks that test data types, formulas and file management.
2. Week 2

   Explain systems in context

   • Write recommendations for specific user scenarios.
   • Test practical outputs with small manually checked datasets.
3. Week 3

   Work to a timed brief

   • Complete stage-appropriate integrated tasks.
   • Collect required evidence and compare every output with the brief.
4. Week 4

   Rebuild weak features

   • Repeat tasks that failed through references, criteria or missing evidence.
   • Rehearse saving, naming and final checking without rushing.

Your questions, answered