Grade 9 AI & Computer Science Practice Questions — Set 11

ExplanationWhether a browser treats the markup inside `<noscript>` as functioning HTML depends entirely on its scripting state: when scripting is enabled, that markup stays inert and unparsed, but when scripting is disabled, the browser parses it exactly like normal page content. Disabling JavaScript therefore activates the nested `.hidden { display: block; }` rule as a genuine, working stylesheet rule. That rule has identical specificity to the earlier `.hidden { display: none; }` rule, since both use a single class selector, so the CSS cascade's tie-breaker applies: whichever matching rule appears later in the document wins, regardless of what the JavaScript toggle was meant to do. This is precisely why the pattern is used for graceful degradation — it guarantees that information meant to be revealed by an interactive toggle is never permanently lost to visitors on older devices, low-end browsers, or networks where JavaScript may fail to load or run.

ExplanationBFS explores nodes in order of increasing distance from the start — it fully processes all nodes 1 edge away before touching any node 2 edges away, and so on. This level-by-level expansion means the very first time BFS discovers the target node, it has done so via the minimum possible number of edges — a mathematical guarantee for unweighted graphs. DFS, by contrast, commits to one path and follows it as deep as it goes before backtracking; it might stumble onto a long, winding path to the exit long before it would find the actual shortest one, with no built-in guarantee of optimality. This is exactly why BFS, not DFS, is the standard choice for unweighted shortest-path problems, while DFS is preferred for tasks like exhaustively exploring all possibilities or detecting cycles.

ExplanationDijkstra's algorithm finds the minimum-total-weight path by greedily expanding the closest unvisited node at each step, always keeping the best-known distance to every node. Checking every route from A to D by hand: A-B-D costs 4+5=9. A-C-D costs 1+8=9. A-C-B-D costs 1+2+5=8. The three-edge path through both C and B, despite using more edges, has the LOWEST total weight at 8 — beating both two-edge alternatives, which is exactly the kind of non-obvious result Dijkstra's algorithm is designed to find correctly (fewer edges does not necessarily mean lower total weight in a weighted graph). Dijkstra's algorithm would correctly settle on distance 8 by continuously relaxing edges: it finds C first (distance 1), then from C it discovers B at distance 1+2=3 (better than the direct A-B edge of 4), and finally from B it reaches D at distance 3+5=8 (better than C-D's direct 1+8=9).

ExplanationIdempotency means: performing the same operation multiple times produces the same end STATE as performing it once. GET is defined by the HTTP spec to be safe and idempotent — it only reads data, so calling it once or a hundred times leaves the server's state identical. POST, however, is conventionally used to CREATE a new resource each time it's called — POST /orders typically means 'create a new order', so calling it twice with an identical body still results in two distinct order records (with different IDs), not one. This exact behavior is why network retries on POST requests are dangerous without extra safeguards (like idempotency keys), while retrying a GET request is always safe. PUT, by contrast, IS conventionally idempotent, since 'replace this resource with this exact state' has the same end result whether done once or five times.

ExplanationA JWT's three dot-separated segments are, in order: (1) the HEADER, base64-encoded JSON describing the signing algorithm and token type (e.g., {'alg':'HS256'}); (2) the PAYLOAD, base64-encoded JSON containing the actual claims — data like userId, expiration time, or roles; and (3) the SIGNATURE, a cryptographic hash computed over the first two parts using a secret key known only to the server, which lets the server verify the token hasn't been tampered with since it was issued. A critical, commonly-missed detail: base64 encoding is NOT encryption — it is trivially reversible by anyone, so the header and payload can be decoded and read by anybody who has the token (never put secrets like a password directly in a JWT payload). Only the signature, which requires the server's secret key to forge correctly, provides real security — it's what makes a tampered payload detectable, not what hides the payload's contents.

ExplanationThe default box-sizing value, content-box, defines the 'width' CSS property as applying ONLY to the content area — padding and border are then added ON TOP of that, expanding the element's actual rendered footprint. Computing it: content width = 200px. Padding applies to BOTH left and right sides: 20px + 20px = 40px. Border also applies to both sides: 5px + 5px = 10px. Total rendered width = 200 + 40 + 10 = 250px. This is a frequent source of unexpected layout bugs, which is exactly why box-sizing: border-box (where the specified width INCLUDES padding and border, making the content area shrink to fit) is so commonly applied as a CSS reset in real projects — it makes the 'width' property mean what most developers intuitively expect.

ExplanationDOM events don't just fire on the exact element clicked — by default they BUBBLE upward through every ancestor element, all the way to the document root. Event delegation exploits this: instead of attaching 1000 listeners (one per li, wasteful in both memory and setup time, and broken for any li added LATER dynamically), you attach exactly ONE listener to a shared ancestor (like the ul). When any li is clicked, the event bubbles up to the ul's listener, which fires once; inside that handler, event.target tells you exactly which specific li was the original click target, so you can respond appropriately. This pattern is both more efficient AND automatically handles dynamically-added list items, since the single listener on the parent doesn't care how many children exist or when they were added.

Explanationgit checkout -b feature-login does two things at once: creates a new branch named feature-login (a separate line of commit history starting from your current position), and switches your working directory to it. Any commits you make next belong to feature-login specifically, leaving main completely untouched — this isolation is the entire point of feature branches, letting you experiment or build a feature without risking main's stability. git checkout main switches back to the main branch. git merge feature-login then integrates feature-login's new commits into main, combining the two histories. This branch-work-merge cycle is the fundamental Git workflow behind nearly all real-world collaborative software development, letting multiple people work on different features in parallel without stepping on each other's changes until merge time.

ExplanationA trie's core structural idea is that words sharing a common PREFIX also share the same PATH through the tree from the root. For 'cat', 'car', and 'card': all three share the letters c-a-r, so the tree has a single c->a->r path used by all three words, only branching apart afterward ('t' for cat, nothing extra marks the end of 'car' itself, 'd' extends to 'card'). This shared-prefix structure is exactly why tries are the standard data structure behind autocomplete and spell-checkers: to find every word starting with 'car', you simply walk down to the 'car' node (following just 3 edges) and then explore everything reachable beneath it — you never need to scan through unrelated words like 'dog' at all, giving lookup time proportional to the PREFIX length, not the total number of stored words.

ExplanationThe alt attribute exists specifically to provide a text alternative to an image's visual content, and its single most important use case is screen-reader software used by blind or low-vision users, who cannot perceive the image visually at all. A well-written alt text (e.g., alt='Bar chart showing 40% revenue growth in Q3 2026') lets a screen reader convey the SAME information a sighted user gets from glancing at the chart. Without it, a screen reader typically falls back to reading the raw filename, which conveys essentially nothing useful ('chart dot p n g'). This is a genuine accessibility gap, not a cosmetic rule — it directly determines whether a meaningful fraction of real users can actually understand your page's content, which is exactly why alt-text auditing is a standard, legally-relevant part of web accessibility compliance (WCAG) in many countries.

ExplanationINNER JOIN returns only the rows where the join condition (Students.id = Grades.student_id) successfully matches a row in BOTH tables — any row from either table with no corresponding match is silently dropped from the result entirely. Aisha (id=1) matches two Grades rows (Math and Science), producing two output rows. Rohan (id=2) matches one Grades row (Math), producing one output row. Meera (id=3) has ZERO matching rows in Grades, so she contributes nothing — not even a row with a NULL score. Total: 2+1+0 = 3 rows, and Meera is completely absent from the result. This is the key distinction from a LEFT JOIN, which would still include Meera exactly once, with score shown as NULL, specifically because LEFT JOIN preserves every row from the left table (Students) regardless of whether a match exists on the right.

ExplanationThe right data structure depends on exactly which operations you actually need. A heap is PURPOSE-BUILT for 'always know the max (or min) quickly, and efficiently remove it, and efficiently add new items' — its structural invariant (every parent >= its children, for a max-heap) guarantees the root is always the maximum, giving true O(1) peek and O(log n) insert/extract, REGARDLESS of what data is inside. A plain (non-self-balancing) BST offers more general capabilities — like arbitrary search, in-order traversal, or range queries — but as a side effect of that generality, an unlucky insertion order can leave it heavily skewed (approaching a straight line), degrading operations like 'find the maximum' from the ideal O(log n) all the way to O(n). For a task that specifically and only needs repeated max-extraction — like a priority queue for task scheduling or Dijkstra's algorithm's frontier — a heap is the simpler, more reliably efficient choice; a self-balancing BST (like a red-black tree) could match a heap's guarantees but at genuinely higher implementation complexity for no added benefit in this narrow use case.

ExplanationTopological sort is specifically defined for Directed Acyclic Graphs (DAGs) and produces exactly what's needed here: a linear sequence of all nodes where every directed edge A->B has A appearing strictly before B. This maps perfectly onto 'A must be compiled before B' dependency constraints. The critical requirement is that the graph must have NO CYCLES — if file A depends on file B, and file B (directly or indirectly) also depends on file A, there is NO valid compile order at all, since satisfying one dependency would require violating the other; this is precisely a 'circular dependency' error that real build tools (like npm, Maven, or Make) detect and report as a build failure. Algorithms like Kahn's algorithm (repeatedly removing nodes with no remaining incoming edges) or a DFS-based approach both compute a valid topological order when one exists, and both can detect the absence of one (a remaining cycle) when it doesn't.

ExplanationREST APIs are typically organized around fixed RESOURCE endpoints, each returning a fixed shape of data — fetching data that spans multiple resources (user info + orders + loyalty points) conventionally means multiple separate HTTP requests, and each individual endpoint might return MORE fields than the client actually needs (over-fetching) or force additional requests to get related data (under-fetching). GraphQL instead exposes a single endpoint where the CLIENT describes precisely the shape of data it wants, across potentially multiple underlying resources, in one query — the server resolves that query and returns exactly the requested fields in one response. For this home-screen scenario, that's the difference between 3 network round-trips (with excess unused data in each) and 1 round-trip carrying only the 5-6 specific fields actually needed — a meaningful real-world performance and simplicity win, especially on mobile networks where each round-trip has real latency cost.

ExplanationBreaking down ^\d{10}$: the caret ^ anchors the match to the very START of the string (nothing is allowed before it matches), \d{10} requires EXACTLY 10 digit characters consecutively (not 'up to 10' — {10} is an exact repetition count, unlike {0,10} or {10,} which would allow ranges), and the dollar sign $ anchors to the very END of the string (nothing is allowed after). Together, these three pieces mean the ENTIRE string, start to finish, must consist of precisely 10 digits and nothing else. '9876543210' (10 digits, no extra characters) matches perfectly. '98765-43210' fails because the hyphen is not a digit character, breaking the \d{10} requirement partway through. '+919876543210' fails at the very start, since + immediately violates the ^\d requirement that the string must BEGIN with a digit. '987654321' has only 9 digits, failing the exact-10 requirement enforced by both the {10} count and the $ end-anchor (which would require the 10th digit to exist before the string can end).

ExplanationA common misconception is that 'async' means a function runs entirely in the background immediately. In reality: an async function runs SYNCHRONOUSLY from its start, right up until it hits its first await — only AT that await point does it pause and return control back to whatever called it. Tracing this code: line 'console.log(C)' runs first as the program executes top to bottom, printing C. Then loadData() is called; INSIDE it, console.log('A') runs immediately (synchronously) before any pausing happens, printing A. Then execution reaches await fetch(...) — THIS is where it pauses, handing control back to the caller without waiting for the network response. Back in the outer code, the very next line, console.log('D'), then runs, printing D. Only later, once the network request actually completes, does execution resume inside loadData() at the point after await, eventually printing B. Final order: C, A, D, and eventually B — demonstrating that await only pauses the function IT'S inside, never the rest of the program.

ExplanationlocalStorage and sessionStorage share the same simple key-value API, but differ in LIFETIME and SCOPE. localStorage data persists indefinitely on the user's device, shared across every tab/window for that origin, until a script or the user explicitly clears it — perfect for a shopping cart that should survive closing and reopening the browser entirely. sessionStorage data is scoped to a single tab's lifetime: it survives a page refresh within that same tab (since the tab itself hasn't closed), but is automatically wiped the moment that specific tab is closed, and is NOT shared with other tabs even on the same site — exactly matching a 'don't show this notice again this visit, but do show it again if they come back later' requirement. Cookies, the third common mechanism, differ from both by being sent with every HTTP request to the server (adding overhead) and having an explicit, settable expiration date rather than being purely tab- or persistence-scoped.

ExplanationEach of .map(), .filter(), and .reduce() is independently O(n): each visits every element of its input array exactly once, doing a constant amount of work per element (assuming the per-element operation itself, like simple arithmetic, is O(1)). Chaining three separate O(n) passes gives a total cost of O(n) + O(n) + O(n) = O(3n). Big-O notation specifically describes how runtime GROWS as input size grows, and constant multipliers (like the 3 here) don't change that growth pattern — doubling n still roughly doubles the total work either way, so O(3n) is written simply as O(n). This is different from NESTING operations (like calling .map() INSIDE a .forEach() over the same array), which would multiply rather than add the costs, giving a true O(n^2). Note real engines do NOT automatically fuse chained .map/.filter/.reduce into one pass by default — each call to genuinely does create its own intermediate array (a real, if often acceptable, extra cost) — but the asymptotic time complexity remains linear either way.

ExplanationBinary search's efficiency comes entirely from being able to eliminate HALF the remaining candidates with each comparison — but that elimination logic ('if the target is smaller than the middle element, it cannot possibly be anywhere in the right half') is only valid when the data is sorted. On an unsorted list, a middle element being larger than your target tells you NOTHING about which half the target might be in — it could be anywhere. Attempting binary search on unsorted data would give incorrect, unreliable results, because the halving logic silently assumes an ordering that isn't actually there. The correct approach for unsorted data is linear search: check every element one at a time until you find a match or exhaust the list, which is O(n) — slower than binary search's O(log n), but it's the correct choice when sortedness isn't guaranteed (or when sorting first would cost more than a single linear scan is worth).

ExplanationA hash map's O(1) average-case performance depends on each bucket holding, on average, only a small, roughly-constant number of keys. As the load factor (keys/buckets) climbs, collisions become more frequent and each bucket's chain (under separate chaining) grows longer — a lookup that has to scan a bucket with 10 entries instead of 1 is doing meaningfully more work, degrading average performance toward the O(n) worst case. Resizing — typically DOUBLING the bucket count once load factor crosses a threshold like 0.75 — restores headroom: with twice as many buckets, the same keys redistribute (via re-hashing, since bucket assignment depends on the bucket COUNT) into shorter average chains again. This resize-and-rehash operation is itself O(n) when it happens, but because it happens rarely (only when the threshold is crossed, and each resize roughly doubles capacity), the AMORTIZED cost per insertion averaged over many insertions stays O(1) — the same trick behind Python list's automatic over-allocation when appending.

ExplanationSince the three requests here have NO dependency on each other (none needs the result of another to begin), sequentially awaiting them one at a time is needlessly slow: await fetch(profile) fully blocks progress until it resolves, and only THEN does the code even begin the orders request, and so on — if each request takes roughly 200ms, the sequential total is roughly 200+200+200=600ms. Promise.all([...]) instead KICKS OFF all three fetch() calls essentially back-to-back (each starts immediately, without waiting for the others), and then waits for every one of them to resolve; since they're now running concurrently rather than one-after-another, total time is roughly bounded by whichever single request takes longest — around 200ms in this example, not 600ms. This is one of the most impactful, easy real-world async-JavaScript optimizations: batch independent async operations with Promise.all() rather than awaiting them one at a time.