Progress test: Levels 1–4

Why each option is right or wrong

• “The RAM” (Incorrect): Half of it is free, so memory isn't limiting.
• “The disk” (Incorrect): Saving the file takes a moment, but the CPU at 100% shows where the time goes.
• “The Wi-Fi” (Incorrect): Exporting is local work; the network isn't used.
• “The CPU” is correct.

  Exporting means heavy calculation: encoding every pixel of the image. With every CPU core at 100% and plenty of RAM free, the processor is the limit. A faster CPU, or one with more cores, would export faster; more RAM wouldn't.

  • Check: Task Manager or Activity Monitor shows which resource is maxed.
  • Some editors: can use the graphics card to speed up exports.

📖 Revise: Module 1: How Computers Work

Why each option is right or wrong

• “The internet connection gets faster” (Incorrect): Local resources were freed; the connection is the same.
• “Closing apps frees up space on the disk” (Incorrect): Disk space doesn't change when apps close, and it isn't what games need while running.
• “The graphics card switches to a faster mode” (Incorrect): The hardware doesn't change; freed CPU and RAM help.
• “More RAM and CPU become available to it” is correct.

  Every running program uses some CPU time and memory. Closing other apps frees those resources, so the game gets more of the processor and RAM, and is less likely to be slowed by swapping to disk.

  • Biggest users: browsers with many tabs, video calls, updates.
  • Check: which apps use the most memory before a game.

📖 Revise: Module 1: How Computers Work

Why each option is right or wrong

• “Readable by everyone on the server (644)” (Incorrect): That exposes secrets to every user and process on the machine.
• “Executable by everyone (755)” (Incorrect): It isn't a program, and everyone could still read it.
• “Full access for everyone (777)” (Incorrect): The most dangerous choice: anyone can read and change it.
• “Readable only by the owner (like 600)” is correct.

  A .env file holds passwords and keys, so only the account that runs the app should be able to read it. Permission 600 means the owner can read and write, and nobody else can do anything.

  • Command: chmod 600 .env.
  • Also: keep it outside the web root.

📖 Revise: Module 2: Operating Systems

Why each option is right or wrong

• “End it immediately to free up the CPU” (Incorrect): If it's an important system task, ending it could crash the computer.
• “Restart the laptop to see if it goes away” (Incorrect): A restart doesn't tell you what it is, and it may come back.
• “Delete the program's file from the disk” (Incorrect): That could remove something essential.
• “Look up its name before ending it” is correct.

  An unfamiliar name might be a normal system task, like an indexing service, or it might be malware. Searching for the name, and checking where its file lives, tells you which. Ending an essential process can crash the system.

  • Check: the publisher and file location.
  • If suspicious: run a security scan.

📖 Revise: Module 2: Operating Systems

Why each option is right or wrong

• “The code has a typo that only the server notices” (Incorrect): It runs fine locally, so the code itself is valid.
• “The server's firewall blocks optional chaining” (Incorrect): Firewalls filter network traffic, not code syntax.
• “The server needs more RAM to run the code” (Incorrect): Syntax errors aren't memory problems.
• “The server runs an older runtime that lacks that syntax” is correct.

  ?. (optional chaining) arrived in Node.js 14. If the server runs an older version, it doesn't understand the syntax and fails before running anything, while your laptop's newer Node runs it happily. Matching runtime versions fixes it.

  • Check: node -v on both machines.
  • Pin: the version in package.json engines or .nvmrc.

📖 Revise: Module 3: Software and Applications

Why each option is right or wrong

• “The download websites are blocked at 3 pm” (Incorrect): Blocked sites wouldn't load at all; these just crawl.
• “The lab computers need faster processors” (Incorrect): CPUs aren't the limit for downloads; the shared line is.
• “The router's admin password is too weak” (Incorrect): A weak password is a security risk, but it doesn't slow traffic.
• “Many devices sharing the same bandwidth at once” is correct.

  One internet line is shared by every device in the lab. When many students download at once, say at 3 pm, each gets a small slice of the bandwidth, so everything slows. At quieter times, each device gets more.

  • Fixes: a faster line, or limits per device.
  • Check: speed tests at busy and quiet times.

📖 Revise: Module 4: Computer Networks

Why each option is right or wrong

• “The web server is down” (Incorrect): The HTML loaded from it, so it's up.
• “The browser has JavaScript turned off” (Incorrect): CSS loads without JavaScript.
• “The DNS lookup failed” (Incorrect): Then nothing would load.
• “The stylesheet's path is wrong or the file wasn't uploaded” is correct.

  The HTML loaded, so the server is up and DNS works. A 404 for the CSS means the browser asked for the stylesheet at a path where nothing exists, because the path is wrong or the file wasn't uploaded. Without CSS, the page shows unstyled.

  • Check: the URL in the Network tab against the real file location.
  • Common causes: wrong case in file names, or a missing folder.

📖 Revise: Module 6: How the Web Works

Why each option is right or wrong

• “A cluster spread across several cloud regions” (Incorrect): Overkill for 20 users.
• “Shared hosting that only runs PHP websites” (Incorrect): It may not support long-running Node.js apps at all.
• “A dedicated physical server” (Incorrect): Far more power and cost than needed.
• “A small managed platform or small VPS” is correct.

  20 users a day need very little. A small managed platform, or a small VPS, runs a Node.js backend cheaply and simply, and you can scale up later when real usage demands it.

  • Managed: less setup and maintenance.
  • VPS: more control, but you maintain it.

📖 Revise: Module 7: Servers and Hosting

Why each option is right or wrong

• “.gitignore only works after the computer restarts” (Incorrect): Git reads .gitignore each time it runs; no restart is involved.
• “Hidden files that start with a dot can't be ignored” (Incorrect): Dot files can be ignored like any other file.
• “The rule needs to be written as *.env* with stars” (Incorrect): .env matches the file exactly; the issue is that it's already tracked.
• “It was committed before, so Git still tracks it” is correct.

  .gitignore only stops Git from picking up files it isn't tracking yet. A file that was already committed stays tracked, so its changes keep showing. Untrack it with git rm --cached .env, commit, and from then on the ignore rule works. If the file held real secrets, change them too, because old commits still contain them.

  • Command: git rm --cached .env removes it from Git but keeps your copy.
  • Check: git check-ignore -v .env shows which rule matches.

📖 Revise: Module 9: Introduction to Git

Why each option is right or wrong

• “Adding a README that asks people not to” (Incorrect): A request in a file can't stop a push.
• “Turning on GitHub Pages for the repo” (Incorrect): Pages publishes a website; it doesn't guard branches.
• “Making the repository private” (Incorrect): Private repos limit who can see it, not what members can push.
• “Branch protection on main” is correct.

  Branch protection rules can block force-pushes and deletion, and require pull requests with passing checks before anything reaches main. The lost commits may still be recoverable from someone's local copy, but protection stops it happening at all.

  • Settings: Repository → Settings → Branches (or Rules).
  • Recover: a teammate with the commits can push them back.

📖 Revise: Module 10: Working with GitHub

Why each option is right or wrong

• “Make the div text larger and bold for clarity” (Incorrect): Size and weight are visual; screen readers can't see them.
• “Put every section title in <strong> tags” (Incorrect): strong marks importance, not a section heading.
• “Add title="heading" to each section div” (Incorrect): The title attribute shows a tooltip; it doesn't create a heading.
• “Real heading tags, h1 then h2, in order” is correct.

  Screen readers list a page's headings so users can jump between sections, much as sighted readers skim bold titles. A div styled to look big carries no meaning, so it isn't on that list. Use one h1 for the page title and h2/h3 for sections, then style them with CSS however you like.

  • Don't skip levels: go h1 → h2 → h3.
  • Check: a headings outline extension, or the browser's accessibility tree.

📖 Revise: Module 11: Introduction to HTML

Why each option is right or wrong

• “The title of the page the link points to” (Incorrect): Screen readers don't look up the destination page's title.
• “Nothing, because screen readers skip image links” (Incorrect): Links are announced; this one just has no useful name.
• “The company name, read from the image automatically” (Incorrect): Screen readers can't reliably read text inside images.
• “Possibly just "link" or the file name” is correct.

  A screen reader announces a link by its text. With only an image and no alt text, there's nothing to read, so it may say just "link" or read out the image's file name. Alt text that names the destination, like "Home", fixes it.

  • Logo links: alt such as "Sharma Textiles home".
  • Test: tab through the page with a screen reader on.

📖 Revise: Module 12: Webpage Content

Why each option is right or wrong

• “A placeholder showing the format, with no label” (Incorrect): Placeholders disappear when typing and aren't a label.
• “A larger text box, so there's more space to type the date in” (Incorrect): Same problem, more space.
• “A note asking people to type it carefully” (Incorrect): Notes don't stop different formats; structured input does.
• “A date input or clear separate fields with a format hint” is correct.

  Free text invites "5/3/90", "March 5 1990" and "05-03-1990", which are hard to read reliably, and some are ambiguous. A date input, or separate day, month and year fields with a clear format hint, collects it consistently.

  • Label clearly: "Date of birth (DD/MM/YYYY)".
  • Validate: on the server too.

📖 Revise: Module 13: Forms and Inputs

Why each option is right or wrong

• “The browser couldn't understand any of the CSS in that file” (Incorrect): Other rules apply fine, so the CSS is being read.
• “The stylesheet file is missing from the server or the folder” (Incorrect): A missing file wouldn't show its rules at all.
• “The rule has a syntax error and was ignored” (Incorrect): Invalid values show with a warning icon; crossed out means overridden.
• “Another, more specific or later rule overrides it” is correct.

  When DevTools shows a rule crossed out, the browser read it, but another rule won for that property, either more specific or later with equal specificity. The Styles panel shows which rule is applied above it.

  • Fix: match or lower specificity rather than adding !important.
  • Check: the Computed tab for the final value.

📖 Revise: Module 14: Introduction to CSS

Why each option is right or wrong

• “Add justify-content: space-between and keep the margins” (Incorrect): That spreads the buttons across the whole row, a different layout.
• “Put a   character between each pair of buttons” (Incorrect): Spacing with characters is fragile and changes with the font size.
• “Add margin-left: -16px to the first button” (Incorrect): Negative margins shift the problem and quickly get confusing.
• “Remove the margins and set gap: 16px on the container” is correct.

  gap adds space only between flex items, not after the last one, so the edges stay aligned. It keeps working when items wrap or are reordered, and it's set in one place.

  • Works in: both flexbox and grid.
  • Margins are still useful: for space outside the whole group.

📖 Revise: Module 15: Page Layouts

Why each option is right or wrong

• “Hide two of the columns on screens under 600px” (Incorrect): That hides products from phone users instead of showing them.
• “Shrink the font size on phones so the words fit” (Incorrect): Tiny text is hard to read; the layout is the problem.
• “Set the columns to a fixed width of 300px each” (Incorrect): Three 300px columns overflow a phone screen, causing sideways scrolling.
• “One column first; more in min-width queries” is correct.

  Mobile-first means writing the base CSS for small screens, then adding layout for wider ones. Here the grid starts as one column, and a query like @media (min-width: 768px) switches to three. Phones get readable cards without extra rules, and laptops still get the grid.

  • Grid: grid-template-columns: 1fr; then repeat(3, 1fr) in the query.
  • No query at all: repeat(auto-fit, minmax(220px, 1fr)) adapts by itself.

📖 Revise: Module 16: Responsive Websites

Why each option is right or wrong

• “Number() turns the text '0' into null” (Incorrect): It turns it into the number 0.
• “The input sends 0 as the word 'zero'” (Incorrect): Inputs send the characters typed, here '0'.
• “! only works on the values true and false” (Incorrect): It works on any value, converting it to true or false first.
• “0 is falsy, so !quantity is true” is correct.

  In conditions, JavaScript treats 0, '', null, undefined, NaN and false as false. So !0 is true and the error shows, even though 0 is a valid answer here. Check for what you really mean, such as input.value === '' or Number.isNaN(quantity).

  • Watch for: 0 and empty strings in form values.
  • Strings: before converting, '0' is truthy; after Number(), it's falsy.

📖 Revise: Module 17: JavaScript Basics

Why each option is right or wrong

• “let can't be used to declare loop counters” (Incorrect): It can, and it's the right choice.
• “<= isn't allowed in the condition part of a for loop” (Incorrect): It's valid, just wrong here.
• “Arrays in JavaScript start at index 1, so the first item is skipped” (Incorrect): They start at 0, which is why the last index is length − 1.
• “The last index is length − 1; <= goes one past the end” is correct.

  Arrays start at index 0, so the last item is at length − 1. With i <= items.length, the loop runs one extra time and reads items[items.length], which is undefined. That's an off-by-one error.

  • Safer: for (const item of items) avoids index mistakes.
  • Rule: < with length, not <=.

📖 Revise: Module 18: Decisions and Functions

Why each option is right or wrong

• “A JavaScript variable in the page script” (Incorrect): Variables are lost on reload.
• “A setting written into the HTML file” (Incorrect): Visitors can't change your files.
• “A query string added to every link” (Incorrect): It's lost as soon as someone opens a page without it, and it clutters URLs.
• “localStorage” is correct.

  A static site has no server storage, but the browser does. localStorage keeps small values, like theme: dark, in that browser across reloads and visits. On load, read it and apply the theme.

  • Respect system settings: prefers-color-scheme as the default.
  • Per device: another browser won't know the choice.

📖 Revise: Module 19: Browser Interactions

Why each option is right or wrong

• “More HTML attributes on the form, like action and method” (Incorrect): HTML can't save data on its own.
• “A JavaScript file that saves messages” (Incorrect): Browser JavaScript can't store messages on the host without a backend.
• “localStorage in each visitor's browser” (Incorrect): That only stays on the visitor's device, so the messages wouldn't reach you.
• “A backend or form service, plus storage” is correct.

  A static host only serves files; it can't receive and save form submissions. You need something that runs code, either your own small backend with a database or a form service that stores messages and emails them to you.

  • Form services: quick to add to static sites.
  • Protect: against spam with a honeypot or CAPTCHA.

📖 Revise: Module 20: Your First Interactive Website

Why each option is right or wrong

• “items.splice(0, 0, newItem)” (Incorrect): Changes the original.
• “items[items.length] = newItem” (Incorrect): Changes the original.
• “items.push(newItem)” (Incorrect): Changes the original.
• “[...items, newItem]” is correct.

  Spread copies the existing items into a new array and adds the new one, leaving items untouched. This matters in React state and anywhere else that relies on detecting changes by comparing references.

  • Also non-mutating: concat, map, filter, slice.
  • Mutating: push, splice, sort, reverse.

📖 Revise: Module 21: Arrays and Objects

Why each option is right or wrong

• “Sort by price twice, then take the last item” (Incorrect): Unnecessary, and the last item is the most expensive.
• “Take the first item, since lists are usually sorted” (Incorrect): Lists aren't sorted unless you sort them.
• “Filter for items with a price of 0” (Incorrect): That finds free items, not the real minimum.
• “A single pass keeping the lowest price seen” is correct.

  To find the lowest price, look at each product once and remember the cheapest so far. A single loop or reduce does it. Sorting the whole list works but does more work than needed and changes the order.

  • Example: items.reduce((min, p) => p.price < min.price ? p : min).
  • Empty list: handle it first.

📖 Revise: Module 22: Loops and Algorithms

Why each option is right or wrong

• “A copy frozen when setTimeout was called” (Incorrect): That isn't how closures work.
• “undefined, since the callback runs later” (Incorrect): It can still see the variable.
• “The value it had when the callback was created” (Incorrect): Closures capture variables, not snapshots, so reassignments are seen.
• “The current value at the time it runs” is correct.

  A closure keeps a link to the variable itself, not a copy of its value. When the callback runs later, it reads whatever the variable holds at that moment, so if it changed in between, it sees the new value.

  • Classic bug: var in loops with timers.
  • Fix: use let in loops, or pass the value in.

📖 Revise: Module 23: Functions and Scope

Why each option is right or wrong

• “The function quietly retries until it eventually succeeds” (Incorrect): There's no automatic retry.
• “The caller throws the error straight away” (Incorrect): Not without await; the error is in the promise.
• “The error is caught and handled automatically by the runtime” (Incorrect): Nothing fixes it.
• “An unhandled rejection; the error may go unnoticed” is correct.

  An async function that throws returns a rejected promise. If nobody awaits it or adds .catch, the rejection is unhandled: you might get a console warning, and in Node it can crash the process, but your code doesn't deal with the error.

  • Rule: await it inside try/catch, or add .catch.
  • Linters: can flag floating promises.

📖 Revise: Module 24: Asynchronous Programming

Why each option is right or wrong

• “Whether the weather API's server has gone down” (Incorrect): A down server usually gives 5xx errors or no response at all.
• “Whether the city name in the request is spelt correctly” (Incorrect): A bad city usually gives 400 or 404, not 401.
• “Whether your internet connection is still working” (Incorrect): You got a response, so the connection works.
• “Whether the API key is missing, mistyped or expired” is correct.

  401 means the server didn't accept your credentials: the key is missing from the request, mistyped, revoked or expired. Check the request headers in the Network tab and the key in your provider's dashboard. A 403, by contrast, means the server knows who you are but won't allow the action.

  • Common causes: a rotated key, a free trial that ended, a renamed header.
  • 429: would mean too many requests instead.

📖 Revise: Module 25: APIs and JSON

Why each option is right or wrong

• “None; passing tests show the code is correct” (Incorrect): Tests only check what they were written to check.
• “AI-written tests can't run in Node's built-in test runner” (Incorrect): They run fine; the question is what they check.
• “The tests will slow the app down for users” (Incorrect): Tests don't run inside the live app.
• “The tests may repeat the code's own mistakes” is correct.

  If the same source writes the code and the tests, the tests can copy its mistakes, such as expecting a wrong total. Read the tests yourself, add cases from the real requirements (empty carts, refunds, discounts at the limit), and watch each test fail at least once so you know it checks something.

  • Try: break the code on purpose and confirm a test catches it.
  • Expected values: take them from the requirements, not from the output.

📖 Revise: Module 26: Debugging and Testing

Why each option is right or wrong

• “Turn strict mode off, since the code ran fine before” (Incorrect): It ran fine on the paths tested so far; the errors show the others.
• “Add // @ts-ignore above each error” (Incorrect): That hides real problems, and the crashes remain.
• “Upgrade TypeScript, as the errors are a compiler bug” (Incorrect): They're real findings from stricter checks.
• “Fix them: each one is a possible crash” is correct.

  Strict mode turns on checks such as strictNullChecks, which point out where a value could be undefined or null while your code assumes it isn't. Each error is a possible crash. Fix them a few files at a time, with checks, defaults or better types.

  • Gradual: fix one module at a time.
  • Avoid: silencing them with ! or any everywhere.

📖 Revise: Module 27: TypeScript Foundations

Why each option is right or wrong

• “For id fields, in case they're added later” (Incorrect): Ids should be required; records need them.
• “When every record is expected to have it” (Incorrect): Then make it required.
• “Whenever it stops TypeScript showing errors” (Incorrect): That hides missing-data bugs.
• “When the value genuinely may be absent” is correct.

  Mark a property optional only when it really can be missing, such as a phone number that some customers don't give. Then TypeScript makes you handle the missing case. If every record has it, make it required.

  • Required: ids, names, created dates.
  • Optional: genuinely optional fields.

📖 Revise: Module 28: Interfaces and Type Design

Why each option is right or wrong

• “Files longer than about 10 lines aren't allowed” (Incorrect): No such rule exists; files can be any length.
• “TypeScript only works across several files” (Incorrect): It works with one.
• “To keep parts of the code private from teammates” (Incorrect): Not the purpose.
• “Each has one job, making code easier to test and change” is correct.

  Each module has one job: inventory handles stock, billing handles bills, the app ties them together. Small modules with clear boundaries are easier to understand, test on their own and change without breaking others.

  • Test: each module separately.
  • Rule: modules talk through their exported functions.

📖 Revise: Module 29: Modules, Classes, Generics and Utility Types

Why each option is right or wrong

• “Static sites can't show photos without a framework” (Incorrect): HTML has shown images since the beginning.
• “React sites rank higher in search engines automatically” (Incorrect): Search ranking doesn't depend on using React.
• “React is needed for any site to work well on phones” (Incorrect): Plain HTML and CSS work well on phones.
• “Plain HTML and CSS may suit it better” is correct.

  React shines when a page has lots of changing state: dashboards, forms, live updates. For fixed text and photos, it adds a build step, more JavaScript to download and more to learn, with little gain. Plain HTML and CSS, or a static site generator, is often simpler and faster.

  • Use React when: the screen changes a lot in response to data or users.
  • Later: you can add React to one interactive part of the site.

📖 Revise: Module 31: Introduction to React

Why each option is right or wrong

• “Nothing, unless the component asks for it” (Incorrect): Children are passed every time; the component chooses whether to use them.
• “"Save" as the title prop” (Incorrect): Only if you pass title explicitly.
• “"Save" as the label prop” (Incorrect): Content between tags goes to children, not label.
• “"Save" as children” is correct.

  Anything between a component's opening and closing tags is passed as the children prop. So <Button>Save</Button> gives the component children: "Save", which it can render inside a <button>.

  • Can be: text, elements or other components.
  • Use: wrappers like cards and layouts.

📖 Revise: Module 32: Components and Props

Why each option is right or wrong

• “Update fullName in a useEffect whenever a name changes” (Incorrect): It works, but adds an extra render and still keeps a copy that can drift.
• “Ask users to type their full name in a third field” (Incorrect): That adds work for users and can still disagree with the other fields.
• “Store all three names in a global variable instead” (Incorrect): React doesn't re-render when plain variables change.
• “Work out fullName from the other two when rendering” is correct.

  fullName is derived data: it can be worked out at any time from firstName and lastName. Keeping a separate copy in state means every update must remember to change it too, and sooner or later one is missed. Calculate it during render, like const fullName = firstName + ' ' + lastName;, so it can't fall out of step.

  • Rule of thumb: keep the smallest state you need; derive the rest.
  • Expensive calculations: useMemo can cache them.

📖 Revise: Module 33: State and Events

Why each option is right or wrong

• “Copy the code into a plain helper function in utils.js” (Incorrect): Plain functions break the rules of hooks unless they're hooks themselves.
• “Store the user in a global variable that each component reads” (Incorrect): React doesn't re-render when a plain global variable changes.
• “Load it in the top component and pass it down ten levels” (Incorrect): Possible, but heavy prop passing; a hook is simpler for reusing logic.
• “Move it into a custom hook such as useCurrentUser()” is correct.

  A custom hook is a function whose name starts with use and that calls other hooks. Moving the shared state and effect into useCurrentUser() lets each component call one line, while each still gets its own state. Fix a bug once and all three benefit.

  • Rules still apply: call hooks at the top level, not inside loops or conditions.
  • Sharing the data itself: use Context or a data-fetching library.

📖 Revise: Module 34: React Hooks

Why each option is right or wrong

• “Only as red borders around the fields” (Incorrect): Colour alone isn't announced and some people can't see it.
• “In a pop-up alert after submitting” (Incorrect): Alerts are disruptive and aren't tied to the field.
• “Only in the browser console, where developers can see it” (Incorrect): Users can't see the console.
• “Linked to the field with aria-describedby” is correct.

  aria-describedby links the error text to the input, so when a screen-reader user reaches the field, they hear its label and the error together. Red borders alone don't reach them.

  • Also: aria-invalid="true" on the field.
  • Focus: move to the first error on submit.

📖 Revise: Module 35: Forms and Validation in React

Why each option is right or wrong

• “Route parameters are only read on the first page load” (Incorrect): They update on every navigation; the effect didn't run again.
• “:id must be a number, so 'E18' can't be read” (Incorrect): Parameters are text and can hold letters.
• “The browser cached E17's page” (Incorrect): React Router changes pages in the browser without fetching new HTML.
• “The data effect doesn't depend on id” is correct.

  React Router reuses the same component when only the parameter changes. If useEffect(() => load(id), []) runs once on mount, it doesn't run again for E18. Add id to the dependency array so the data reloads whenever the route parameter changes.

  • Read it with: const { id } = useParams();.
  • Cleanup: ignore late responses for the previous id.

📖 Revise: Module 36: Routing

Why each option is right or wrong

• “For a single button's hover state inside one component” (Incorrect): Keep that local to the button.
• “For every piece of state in the app, to keep it in one place” (Incorrect): That causes needless re-renders.
• “To replace the database for data that needs saving” (Incorrect): Context is in memory and is lost on reload.
• “For data many distant components need, like the signed-in user” is correct.

  Context lets distant components read shared data without passing props through every layer. It suits data many parts of the app need and that changes rarely, like the signed-in user or theme.

  • Keep local: state only one component uses.
  • Server data: usually better in a data-fetching library.

📖 Revise: Module 37: State Management

Why each option is right or wrong

• “A blank page until everything has loaded” (Incorrect): Looks broken.
• “An error message straight away, until data arrives” (Incorrect): Nothing has failed yet.
• “The data from the previous visit, without saying so” (Incorrect): Stale data shown as current can mislead; at least mark it as updating.
• “A clear loading state” is correct.

  While data loads, show that something is happening, such as a spinner or skeleton placeholders. Without it, users see a blank or broken-looking page and may leave or click again.

  • Skeletons: reduce layout jumps.
  • Plan for: loading, error and empty states.

📖 Revise: Module 38: API Integration

Why each option is right or wrong

• “A try/catch around <Chart /> in the parent” (Incorrect): Render errors in child components aren't caught by the parent's try/catch.
• “Turning off React's strict mode” (Incorrect): Strict mode only adds checks in development; it doesn't cause the crash.
• “A useEffect that reloads the page on errors” (Incorrect): The crash comes back after each reload.
• “An error boundary around the widget” is correct.

  When a component throws while rendering, React removes the whole tree unless an error boundary catches it. Wrapping the chart in one shows a fallback like 'Chart unavailable' in its place, while the rest of the dashboard keeps working. Log the error so you can fix it.

  • Library: react-error-boundary gives a ready-made component.
  • Not caught: errors in event handlers and async code; handle those with try/catch.

📖 Revise: Module 39: Frontend Quality

Why each option is right or wrong

• “The font isn't the right one for numbers” (Incorrect): Fonts matter less than showing what matters.
• “The metrics aren't updated in real time” (Incorrect): Update speed isn't the problem; priority is.
• “There aren't enough metrics on the screen” (Incorrect): More metrics would make it worse.
• “Nothing stands out as needing action” is correct.

  When everything is the same size, nothing guides the eye. Users can't tell which numbers matter or need action. A good dashboard highlights the few key metrics and makes problems stand out.

  • Lead with: 2–4 key numbers.
  • Show: change and context, not just totals.

📖 Revise: Module 40: Dashboard Project

Why each option is right or wrong

• “Reinstall Express, since the package must be broken” (Incorrect): The package is fine; Node is reading the file as CommonJS.
• “Upgrade to the newest version of Express” (Incorrect): Express works either way; the module setting is the issue.
• “Move the import line to the bottom of the file” (Incorrect): Where the line sits doesn't change how Node reads the file.
• “Set "type": "module" in package.json” is correct.

  Node treats .js files as CommonJS by default, which uses require. To use import, set "type": "module" in package.json (or name files .mjs). Pick one style per project to avoid mixing them.

  • CommonJS: const express = require('express');.
  • ES modules: local imports need extensions, like ./routes.js.

📖 Revise: Module 41: Node.js Fundamentals

Why each option is right or wrong

• “req.body.full” (Incorrect): No body here.
• “req.headers.full” (Incorrect): Not a header.
• “req.params.full” (Incorrect): Params come from the path.
• “req.query.full” is correct.

  Express puts path placeholders in req.params and the query string, everything after ?, in req.query. So id is req.params.id and full is req.query.full, as a string.

  • Note: query values are strings: "1", not 1.
  • Validate: both params and query.

📖 Revise: Module 42: Web Servers with Express

Why each option is right or wrong

• “Moving all the queries into the route handlers” (Incorrect): That spreads data access even wider.
• “Staying on SQLite, since databases can't be swapped” (Incorrect): They can; the structure decides how painful it is.
• “Writing every query as a stored procedure” (Incorrect): That ties the logic even more tightly to one database.
• “A repository layer that holds all the data access” is correct.

  A repository groups the code that reads and writes one kind of data, like enquiryRepo.findById(id). Services call the repository, not the database. Switching databases, or fixing a query, then touches one layer, and services can be tested with a fake repository.

  • Example: enquiryRepo.create(data), enquiryRepo.listOpen().
  • Tests: swap in an in-memory repository.

📖 Revise: Module 43: Backend Architecture

Why each option is right or wrong

• “The site blocks every sign-in from other countries” (Incorrect): Some sites do, but the second factor is what's described here.
• “Passwords from old leaks stop working on their own” (Incorrect): Leaked passwords stay valid until someone changes them.
• “The authenticator app encrypts the password” (Incorrect): It generates short-lived codes; it doesn't change the password.
• “The second factor on their phone” is correct.

  Multi-factor authentication asks for a second, different kind of proof: something you have, like a phone with an authenticator app, as well as something you know. A leaked password alone isn't enough. Passkeys go further, because they won't work on a fake site.

  • Still change: the leaked password, and check where else it was used.
  • Backup codes: kept safely, for a lost phone.

📖 Revise: Module 44: Authentication

Why each option is right or wrong

• “Turning logs off to save disk space” (Incorrect): Then there's nothing to find.
• “Keeping logs on each server and reading them over SSH” (Incorrect): That's the slow way described.
• “Logging more lines, with more detail, on every request” (Incorrect): More unstructured text is harder to search, not easier.
• “JSON logs that share a request ID” is correct.

  Structured (JSON) logs have fields you can filter on, like level, user and route. A request ID, created at the start of each request and added to every log line, lets you pull one request's whole story across servers. Sending all logs to one place makes them searchable.

  • Show the ID: on error pages, so customers can quote it.
  • Leave out: passwords and card numbers.

📖 Revise: Module 45: Files and Logging

Why each option is right or wrong

• “Run the tests only at night, when fewer people notice” (Incorrect): Still slow, and the inbox still fills.
• “Delete the sign-up tests, since emails can't be tested” (Incorrect): A test double tests it; deleting loses coverage.
• “Use the production email account for realistic delivery” (Incorrect): That risks emailing real customers.
• “A test double for the email service” is correct.

  A mock or fake stands in for the email service during tests. The test checks that your code asked to send the right email to the right address, without contacting the provider. Tests become fast and repeatable, and nobody gets emailed. Check the real provider separately, lightly.

  • Check: that sendEmail was called with the new user's address.
  • Balance: the more you mock, the less of the real system you test.

📖 Revise: Module 46: Backend Testing

Why each option is right or wrong

• “302 Found, redirecting the client to the new item” (Incorrect): Redirects are for browsers moving between pages, not API results.
• “202 Accepted, since the enquiry was accepted” (Incorrect): 202 means queued for later, not saved.
• “200 OK, with the word 'created' in the body” (Incorrect): It works, but hides the meaning in text that clients must read.
• “201 Created, with the new item or its address” is correct.

  201 Created tells the client a new resource exists. It's common to return the new item in the body and its address in a Location header, like /enquiries/E42. 200 OK works, but carries less meaning, so clients have to guess.

  • Other codes: 204 for success with no body, 400 for invalid input.
  • Be consistent: across all endpoints.

📖 Revise: Module 47: REST API Design

Why each option is right or wrong

• “Sending reset links by SMS instead of email” (Incorrect): SMS floods cost more and annoy users just as much.
• “A CAPTCHA on the sign-in page” (Incorrect): The reset endpoint is the one being abused.
• “Longer password-reset tokens” (Incorrect): Token length doesn't stop the emails being sent.
• “Rate limits per address and per IP” is correct.

  Rate limits cap how often an endpoint can be called, say five reset emails per address per hour. Limit by IP too, and return 429 Too Many Requests when the limit is passed. This protects users from spam and your email costs, and slows attackers testing which emails exist.

  • Same reply: 'If an account exists, we've sent an email', either way.
  • Monitor: spikes in reset requests.

📖 Revise: Module 48: API Security

Why each option is right or wrong

• “Asking developers to remember to update the docs” (Incorrect): Memory is exactly what failed here.
• “Removing the docs so partners read the code instead” (Incorrect): Partners usually can't see your code.
• “Making every field optional so nothing breaks” (Incorrect): Then the API can't insist on the data it needs.
• “Docs generated from the validation schema” is correct.

  When validation and docs come from one schema (for example, zod schemas turned into OpenAPI), changing the rule changes the docs too. Add a contract test in CI that compares responses with the spec, and announce breaking changes, ideally in a new version.

  • Breaking change: a new required field breaks existing clients.
  • Changelog: tell partners before it ships.

📖 Revise: Module 49: API Documentation

Why each option is right or wrong

• “Click quickly through every screen, finished or not” (Incorrect): Breadth without a working journey looks unfinished.
• “Talk through the list of tools in your tech stack” (Incorrect): A list of tools doesn't show what you built.
• “Walk through the code, one file at a time” (Incorrect): Five minutes of code rarely shows the app working.
• “One real journey, then one design choice” is correct.

  A demo should prove the app works for a real user: sign in, create an enquiry, see it in the dashboard, update its status. Then spend a minute on one decision, like how roles are checked on the server, and what you'd improve. That shows capability, not just screens.

  • Prepare: sample data, and a short recording in case the network fails.
  • Be honest: name the known limits.

📖 Revise: Module 50: Full-Stack Integration

Why each option is right or wrong

• “A memory leak; restart the server nightly” (Incorrect): Memory isn't growing here; the cost is the number of round trips to the database.
• “A race condition; add a lock” (Incorrect): Nothing is competing for the same data; the queries are just too many.
• “Cache stampede; add more cache servers” (Incorrect): A stampede is many requests rebuilding one cache entry at once, not one page making many queries.
• “The N+1 query problem; fetch all customers in one joined or batched query” is correct.

  N+1 means one query for the list, plus one more for each row. With 50 enquiries that's 51 queries, and it grows with the data. Fetching all customers at once, with a join or a single IN (...) query, keeps it to one or two.

  • Spot it: query logs show many similar queries.
  • ORMs: use eager loading options.

📖 Revise: Module 43: Backend Architecture