Grade 9 AI & Computer Science Practice Questions — Set 1

ExplanationDOM modifications are expensive because the browser may recalculate CSS styles, layout positions (reflow), and pixel painting (repaint) after each change. 1000 appends = potentially 1000 reflows. DocumentFragment is an in-memory container that batches changes — you build the entire subtree first, then append the fragment once, triggering only a single reflow/repaint cycle. This reduces layout thrashing from O(n) reflows to O(1), which is critical for smooth 60fps rendering.

ExplanationFirst, the naive recursive Fibonacci has time complexity O(2ⁿ) because each call branches into TWO sub-calls, creating an exponential call tree. For fib(40), the number of function calls exceeds 300 million. Then, the key waste: fib(38) is computed 2 times, fib(37) is computed 3 times, fib(30) is computed thousands of times. The fix is memoization or dynamic programming, which reduces it to O(n). Option B incorrectly multiplies — two branches don't mean n². Option C would be true WITH memoization, but not for the naive version. Finally, option D misapplies merge-sort analysis — the Fibonacci tree is NOT balanced (left subtree is always deeper than right).

ExplanationFirst, a B-tree index on 'score' organizes values in a balanced tree structure. To find score > 90, the database traverses the tree to the first value > 90 (O(log n) ≈ 16 comparisons for 50,000 rows), then scans sequentially from there. Then, without the index, the database must read ALL 50,000 rows (full table scan). The ORDER BY also benefits because the index stores values in sorted order. Option B is wrong — indexes don't cache tables; that's the buffer pool's job. Option C correctly describes this optimization. Finally, option D is wrong — indexes don't compress data; they create a separate lookup structure.

ExplanationJavaScript's event loop has a strict priority order: (1) Synchronous code on the call stack executes first, so '1' and '4' log immediately. (2) The microtask queue (Promises, queueMicrotask, MutationObserver) runs next, so '3' logs. (3) The macrotask queue (setTimeout, setInterval, I/O) runs last, so '2' logs. Even though setTimeout has a 0ms delay, it goes to the macrotask queue, which always runs only after the microtask queue is fully drained. This ordering is specified in the HTML spec's event loop processing model. Promise chains always complete before any timer fires in the same tick, which is exactly why the output is 1, 4, 3, 2.

ExplanationFor the 500 response, fetch() itself resolves successfully — the browser did receive a real HTTP response from the server, so the promise settles normally rather than rejecting. Inside the try block, response.ok is false (only status codes 200-299 are considered "ok"), so the code takes the `if (!response.ok)` branch and returns `{ error: 'Request failed with status 500' }` immediately, using the template literal to correctly interpolate response.status as 500. The catch block is never entered for this case. For no internet connection, there is no server to respond at all, so fetch() cannot establish a connection; it rejects its own promise with a TypeError (commonly with the message "Failed to fetch"). This sends execution straight to the catch block, which returns `{ error: 'Network error: ' + error.message }`. The rule this tests: fetch() only rejects on network-level failures — DNS lookup failure, no connection, CORS blocks — and never on HTTP status codes, even 404 or 500. Checking `response.ok` inside the try block is the only way to detect HTTP-level errors, since they never trigger the catch block on their own.

ExplanationFirst, BST insertion for [5,3,7,1,4,6,8]: 5 becomes root. 3<5 → left of 5. Then, 7>5 → right of 5. 1<5,<3 → left of 3. 4<5,>3 → right of 3. 6>5,<7 → left of 7. 8>5,>7 → right of 7. Inorder traversal (Left-Root-Right) visits: left subtree of 5 first → [left of 3=1, root 3, right of 3=4], then root 5, then right subtree → [left of 7=6, root 7, right of 7=8]. Result: [1,3,4,5,6,7,8] — sorted! This is the BST invariant: inorder traversal ALWAYS produces sorted output. This property makes BSTs ideal for ordered data operations: range queries, finding min/max, and predecessor/successor lookups — all in O(h) time where h is tree height.

ExplanationTrace it level by level. Splitting phase: [8,3,5,1,9,2,7,4] splits into [8,3,5,1] and [9,2,7,4], each splitting again down to single elements — no comparisons happen during splitting, only during merging. Merging back up: Level 1 (pairs of single elements) — merge([8],[3]) compares 8<=3 (false), appends 3 then 8: 1 comparison. merge([5],[1]) compares 5<=1 (false): 1 comparison. merge([9],[2]): 1 comparison. merge([7],[4]): 1 comparison. Level 2 (pairs of size-2 lists) — merge([3,8],[1,5]) needs 3 comparisons to produce [1,3,5,8]. merge([2,9],[4,7]) needs 3 comparisons to produce [2,4,7,9]. Level 3 (final merge of the two size-4 halves) — merge([1,3,5,8],[2,4,7,9]) takes 7 comparisons to interleave into [1,2,3,4,5,7,8,9]. Total: 1+1+1+1+3+3+7 = 17 comparisons, confirmed by executing the exact code above. This also explains the O(n log n) bound: there are log₂(8)=3 merge levels, and each level's merges together touch at most all 8 elements, giving an upper bound of n×log₂n = 24 comparisons — but the true count is 17 because every merge stops comparing as soon as one side empties, after which the rest is appended for free with no more comparisons.

ExplanationPromise.finally(callback) runs its callback once the promise settles, whether it resolves or rejects, and receives no value or error — unlike .then() (runs only on resolve) or .catch() (runs only on reject). If the fetch succeeds, .then() logs 'Success: ...' and finally() then logs 'Request complete'. If it fails instead, .catch() logs 'Error: ...' and finally() still logs 'Request complete'. This guaranteed execution makes finally() ideal for cleanup work — closing connections, hiding loading spinners — that must happen regardless of how the promise resolves.

ExplanationBST search compares the target to node.value at each step: equal returns True, less means all matches must be in the left subtree (go left), greater means go right. Tracing target=2 in the tree built from insertions 5, 3, 7, 1, 9, 2: start at 5, since 2<5 go left to 3; since 2<3 go left to 1; since 2>1 go right, landing on 2, which matches, so search returns True. Time complexity depends on tree height, since each recursive call descends exactly one level: a balanced BST has height O(log n), so search visits O(log n) nodes on average; an unbalanced BST (for example, nodes inserted in sorted order) can degenerate into a linked list of height O(n), making search O(n) in the worst case. This is why self-balancing trees like AVL and Red-Black trees guarantee O(log n) height regardless of insertion order.

ExplanationFirst, loss function quantifies prediction error. MSE = mean of squared differences = ((1.1-1)² + (2.2-2)² + (2.9-3)²) / 3 = (0.01 + 0.04 + 0.01) / 3 = 0.06 / 3 = 0.02. Then, goal: minimize loss by adjusting weights. Backpropagation computes ∂loss/∂weight (gradient), then updates weight -= learning_rate × gradient. Each epoch, loss decreases (ideally). Other loss functions: (1) Binary CrossEntropy for classification (0/1), (2) Categorical CrossEntropy for multi-class, (3) MAE (Mean Absolute Error) for regression. Choosing loss matters: MSE penalizes large errors heavily (outlier-sensitive), MAE treats all errors equally. During training, monitor loss: if loss plateaus, learning rate is too low or stuck in local minimum; if loss oscillates, learning rate is too high.

Explanationvar i is hoisted to the top of the enclosing function scope, not the for-block, so every iteration of the loop (i=0, then 1, then 2) updates that one single variable rather than creating a new binding each time. The loop exits when the condition i<3 fails, which happens once i has been incremented to 3, and that final value of 3 remains in the variable after the loop ends. Because console.log(i) executes in the same function scope where var i lives, it prints 3. Had the loop used let i instead, i would be scoped to the for-block itself; once the loop finished, that binding would no longer exist outside the block, so console.log(i) would throw a ReferenceError instead. This is exactly why let is generally preferred over var for loop counters—it keeps the variable from leaking into the surrounding scope.

ExplanationBinary search has O(log n) time complexity, so for 10,000 elements it needs about log₂(10,000) ≈ 13.3, which rounds up to a maximum of 14 iterations in the worst case, since each comparison discards half of the remaining elements. Linear search has O(n) complexity, requiring up to 10,000 iterations because in the worst case it must check every element one at a time until it finds a match. This gap matters for large datasets because it grows with array size: doubling the array to 20,000 elements adds only one more iteration to binary search (log₂(20,000) ≈ 14.3) while linear search's worst case doubles to 20,000, so binary search stays fast even as datasets scale far beyond 10,000 elements.

ExplanationFirst, f(5) = F(4) + F(3) creates a recursion tree where F(4) is calculated once, F(3) twice, F(2) three times, F(1) five times, and F(0) three times, totaling 15 calls. This exponential growth O(2^n) demonstrates why recursion inefficiently recalculates values. Then, an iterative approach computes each value once in linear O(n) time with only 5 iterations, showing this is critical optimization because without memoization, F(30) requires 2,692,537 calls.

ExplanationBubble sort is O(n²), so its worst-case comparison count is n(n-1)/2 = 100×99/2 = 4,950. Merge sort is O(n log n), so its maximum comparisons are about 100 × log₂(100) ≈ 100 × 6.64 = 664. Dividing 4,950 by 664 gives roughly 7.5, so merge sort needs about 7.5 times fewer comparisons than bubble sort here. This is exactly why the difference matters for algorithm selection: as the input size n grows, an O(n²) comparison count grows far faster than an O(n log n) one, so the efficiency gap only widens, making merge sort the far more scalable choice for large datasets.

ExplanationSequential operations execute one after another: 200ms (fetch) + 150ms (process) + 50ms (display) = 400ms total wait, because process data cannot begin until fetch user data returns its result — there is no independent step here to overlap. Async/await produces the exact same 400ms execution time as the Promise chain; rewriting .then() chains as await statements changes only how the control flow reads (linear statements instead of nested callbacks, with try/catch for errors), not the order or duration of the underlying operations. Execution order still matters for user experience because the 400ms is a real, unavoidable wait the user perceives — showing a loading state or breaking the work into smaller feedback steps are the actual ways to make that wait feel shorter, not parallelizing steps that depend on each other's output.

ExplanationSemantic elements carry meaning beyond their visual style. Because <nav> and <article> have implicit ARIA landmark roles built into the HTML5 spec, assistive technology exposes them in the accessibility tree as jump-to targets — a screen reader user can go directly to the site menu or to one post without reading through every line of visible text, something a generic <div>, which has no implicit role, cannot offer. The <time datetime="2026-08-12"> element separates the human-readable label from a machine-readable value: the datetime attribute is a fixed ISO-8601 string, so a crawler or calendar tool reads exactly one date no matter how the visible text is formatted. That resolves a real ambiguity in something like "8/12/2026," which US readers take as August 12 but most other readers would take as 12 August — an ambiguity a <div> does nothing to fix. The claim that semantic tags are purely stylistic and parse identically to <div> ignores that HTML5 tag names are exposed as distinct roles in the accessibility tree, not just CSS hooks. The claim about an automatic ranking boost tied to counting five-plus semantic tags confuses correlation with mechanism — any indexing benefit comes from crawlers extracting cleaner structure and metadata, not from a rule that rewards tag quantity. And <figure>/<figcaption> do not remove content from the accessibility tree; they group an image with its caption so assistive technology presents them together, the opposite of skipping them.

ExplanationA plain GET fetch like this one is a "simple request," so the browser does not hold it back or ask permission first — it goes out over the network, the payments server processes it normally, and a response comes back with the JSON data attached. CORS enforcement happens only on the receiving end, inside the browser: once the response arrives, the browser checks for an Access-Control-Allow-Origin header that permits shop.example.com, and finding none, it blocks the page's own JavaScript from reading the response body. The data was fetched successfully; only the script's access to it was denied. This reveals the core limitation: CORS is a rule that browsers agree to follow, not a barrier the server enforces against the outside world. A request made with curl, a mobile app, a server-to-server call, or Postman never goes through a browser's CORS check at all, so it receives the full response regardless of any Access-Control-Allow-Origin header. That is why an API that truly needs protection cannot rely on CORS headers as its defense — it needs real authentication (like JWTs or OAuth tokens) that is checked on every request, independent of who or what is making it.

ExplanationWHERE status = 'completed' runs first and removes the two pending rows (order 4 for C2, order 8 for C1), leaving six rows: C1-200, C1-150, C2-300, C3-400, C3-250, C3-100. GROUP BY customer_id then forms three groups: C1 has 2 rows summing to 350, C2 has 1 row summing to 300, C3 has 3 rows summing to 750. HAVING COUNT(*) >= 2 is evaluated after grouping and checks each group's row count, not its total: C1's count of 2 and C3's count of 3 both pass, but C2's count of 1 fails, so that entire group is dropped and its total of 300 never reaches the output. GROUP BY itself never discards or merges away individual rows from a passing group — it only combines rows for aggregation, so both of C1's completed orders are counted. Finally, ORDER BY total DESC sorts the two surviving groups from the largest total to the smallest, putting C3 (750) ahead of C1 (350).

ExplanationFirst, overfitting evaluation: acceptable train-validation gap is roughly 1-3% for well-regularized models, 3-5% for normal models, and above 5% typically signals overfitting. At a 4% gap, this model shows mild overfitting but is not severely overfit. Second, accuracy assessment: whether 68% validation accuracy is adequate is use-case dependent rather than a fixed cutoff. For medical diagnosis (detect disease): 68% sensitivity is too low (misses 32% of cases). For an email spam filter: 68% true positive rate is inadequate (too much spam reaches the inbox). For fraud detection needing near-98% precision: 68% is far too low. For a recommendation system where roughly 70% accuracy is typically acceptable: 68% is borderline acceptable. Production readiness therefore depends on the deployment context rather than a single blanket number: for high-stakes, precision-critical applications this model is not ready, while for lower-stakes applications like recommendations it sits close to acceptable. A full readiness check should also weigh (1) F1-score, since the precision-recall trade-off matters more than raw accuracy, (2) error analysis for systematic bias, and (3) a planned A/B test before full deployment. Improvement strategy: increasing regularization (e.g., L2 lambda around 0.05) would likely narrow the gap and lift validation accuracy slightly, and feature engineering could yield further gains. Finally, post-deployment: monitor for accuracy degradation due to distribution shift, since real-world data differs from training data.

ExplanationArray.prototype.sort() with no compare function does NOT sort numbers by value — it converts every element to a string with String(x) and orders those strings by UTF-16 code unit (lexicographic/dictionary) comparison. For nums = [10, 1, 2, 21, 3], the string forms are "10", "1", "2", "21", "3". Comparing them character by character: "1" is a prefix of "10", so "1" < "10"; comparing "10" and "2" looks only at the first character ('1' vs '2'), so "10" < "2"; similarly "2" < "21" (prefix rule) and "21" < "3" (first character '2' vs '3'). That gives the string order "1" < "10" < "2" < "21" < "3", which maps back to the numeric array [1, 10, 2, 21, 3] — verified directly in Node.js. This is one of JavaScript's most common gotchas: sort() is NOT numeric by default for any input type, it is always string-based unless you supply a compare function such as (a, b) => a - b (ascending) or (a, b) => b - a (descending). It also mutates the original array in place and returns a reference to that same array, rather than creating a sorted copy.