Grade 9 AI & Computer Science Practice Questions — Set 2

ExplanationTarjan's classic result on Union-Find shows the two optimizations must work together: union by rank keeps tree height at O(log n) so no single union or find degrades badly, while path compression rewires every node touched during a find() so it points directly at the root, which pays off on every subsequent find() involving those nodes. The combined effect, analyzed across a whole sequence of m operations on n elements, is an amortized bound of O(alpha(n)) per operation, where alpha is the inverse Ackermann function. Because alpha(n) grows so slowly, it stays at 4 or below for every n up to a number far larger than the number of atoms in the observable universe (roughly 10^80), so in every practical setting the amortized cost per operation is effectively constant. This is an amortized guarantee over the full operation sequence, not a per-call worst case: an individual find() call early in the sequence, before any compression has happened, can still walk a chain of length up to O(log n); it is only the average cost over many calls that is bounded by alpha(n). The two techniques are also not interchangeable substitutes — union by rank on its own bounds tree height at O(log n) but does not independently deliver the alpha(n) bound, and dropping rank tracking in favor of compression alone loses the guarantee that trees stay balanced between compressions.

ExplanationExpress matches routes strictly in the order they are registered, not by specificity. Since app.get('/users/:id', ...) is defined first, a request to /users/profile matches it immediately — ':id' is a wildcard for any single path segment, so it captures 'profile' as req.params.id. The handler calls res.send('User ID: profile'), which sends the response and ends the request-response cycle right there. The second route, app.get('/users/profile', ...), is never reached — it becomes dead code unless the more specific literal route is moved above the parameterized one. Option B describes 'longest/most-specific match wins' routing, which some frameworks use but Express does not — Express is purely order-based. Option C is wrong because Express performs no route-conflict validation at startup; overlapping routes are legal (and a common source of real bugs). Option D is wrong because res.send() finalizes the response — a second handler cannot also write to the same response without an explicit next() call, and attempting to would throw 'Cannot set headers after they are sent'.

ExplanationMutationObserver does not call its callback the instant each DOM change happens. Instead, every change is recorded as a separate MutationRecord, and the browser waits until the current synchronous block of JavaScript finishes running before delivering all the records collected so far as one array in a single callback call. In this code, the for loop runs from start to finish without ever handing control back to the browser, so all five appendChild() calls happen back to back, each producing its own MutationRecord for the added node. Because the loop never pauses, those five records are grouped together and handed to the callback in one delivery once the loop completes. So the callback runs exactly once, and mutationsList.length is 5. It would only fire five separate times if each appendChild() were somehow separated by a point where the browser could hand control back to the event loop (for example, if each call were wrapped in its own setTimeout). The childList option reports both additions and removals of child nodes, not removals only, so the observer does fire here. And observe() itself never triggers the callback — the callback only runs in response to actual mutations, so a length of 0 immediately after calling observe() would mean nothing had happened yet, which is not the case once the loop runs.

ExplanationgetElementsByClassName() returns a live HTMLCollection — a view that automatically re-evaluates which elements currently match "item," not a frozen snapshot. Label the five items by their original order: e0, e1, e2, e3, e4; all start in the collection, so items.length is 5. i=0: items[0] is e0. Removing its class means e0 no longer matches "item," so the live collection instantly re-computes to [e1, e2, e3, e4] and length drops to 4. i=1: items[1] is now e2 (the collection shifted left after e0 left). Removing its class shrinks the collection to [e1, e3, e4], length 3. i=2: items[2] is now e4. Removing its class shrinks the collection to [e1, e3], length 2. i=3: the loop checks 3 < items.length, i.e. 3 < 2, which is false, so the loop stops. Three elements (e0, e2, e4) had their class stripped, while e1 and e3 were never visited because the shrinking, re-indexing collection kept sliding later elements into positions the loop had already passed. That leaves exactly two elements — e1 and e3 — still carrying the class "item." The fix is to iterate over a static copy, e.g. Array.from(items) or a reverse loop, so removals don't reshuffle the indices you're about to read. This liveness behavior is also why querySelectorAll (which returns a static NodeList) does not have this bug: it fixes its matched set at call time instead of tracking the DOM continuously.

ExplanationWork through the line-packing algorithm item by item, adding each item's 120px basis plus a 20px gap before it (gaps sit only between items, never at the container's edges): item1 = 120px; +gap+item2 = 120+20+120 = 260px; +gap+item3 = 260+20+120 = 400px; +gap+item4 = 400+20+120 = 540px — all still ≤ 600px, so items 1-4 stay on line 1. Testing item5 next: 540+20+120 = 680px > 600px, so item5 cannot join line 1 and starts line 2 instead. Line 1's actual used width is therefore 4 × 120px + 3 × 20px = 480 + 60 = 540px, leaving 600 − 540 = 60px empty at the end of the line. Line 2 then takes item5 and item6: 120+20+120 = 260px used, leaving 600 − 260 = 340px empty. Because flex-grow is explicitly set to 0 on every item, none of that leftover space is distributed to the items — flex-grow only kicks in when it is a positive number, so each item remains fixed at exactly 120px wide on both lines, and the unused space simply sits after the last item on each line (the default justify-content: flex-start behavior).

Explanationgrid-template-columns: 100px 2fr 1fr defines three tracks: one fixed-width track and two flexible fr tracks. The grid algorithm always lays out non-flexible tracks first, so the browser reserves exactly 100px for the first column before anything else is computed. What's left over is the container width minus that reserved amount: 700px − 100px = 600px. This leftover 600px is then divided among the fr tracks in proportion to their fr values. The two fr values, 2fr and 1fr, sum to 3 fr total, so each fr unit is worth 600px ÷ 3 = 200px. The second column, sized at 2fr, receives 2 × 200px = 400px, and the third column, sized at 1fr, receives 1 × 200px = 200px. Adding all three together — 100px + 400px + 200px = 700px — matches the container's declared width exactly, with no leftover and no overflow. This is the defining behavior of the fr unit: it distributes only the space remaining after every fixed-size (or content-sized) track has already claimed its share, never the container's full width.

ExplanationExpress keeps matching route handlers in a stack, ordered by registration, and only moves from one to the next when the current handler explicitly calls next(). Tracing this request to /product/55: the first handler matches, prints "Middleware A", and calls next() with no work done on the response — so Express advances to the second matching handler. That handler prints "Middleware B" and calls res.send("Found"), which writes the response body, sets the headers, and calls the underlying res.end() to close out the HTTP response. Because this handler never calls next(), Express has no instruction to continue down the route stack, so the third handler — the one that would log "Middleware C" and send "Also found" — is never invoked at all, not logged and not executed. The client therefore receives exactly "Found" as the response body, and the terminal shows only two lines: "Middleware A" then "Middleware B". This is precisely why Express middleware chains rely on next() as an explicit hand-off signal rather than auto-advancing through every matching route, and why calling res.send() is treated as the end of a handler's involvement in that request-response cycle.

ExplanationA transaction wraps multiple statements so that COMMIT applies all of them together and ROLLBACK undoes all of them together — this is atomicity, one of the four ACID properties (Atomicity, Consistency, Isolation, Durability). Suppose account 1 starts with 1000 and account 2 with 500 (total 1500): a fully successful transaction would leave account 1 at 900 and account 2 at 600, total still 1500. But here the second UPDATE fails because account_id = 2 does not exist, so the database rolls back the entire transaction — account 1's balance reverts to 1000, exactly as if neither statement had run. Atomicity is what stops the 100 units from being deducted from account 1 without ever reaching account 2; without it, the total across accounts would drop to 1400 and the missing 100 units would be unaccounted for.

ExplanationWhen client 1 sends a message, the server's message handler fires once, and inside it wss.clients.forEach() iterates over the full client set — client1 through client5. For each client, the code checks client.readyState === WebSocket.OPEN; since all 5 are open, each one receives a call to client.send("Broadcast: " + msg). That produces exactly 5 send calls, hence 5 broadcast frames, and because the sender is never excluded from wss.clients, client 1 also receives its own message echoed back — a common pattern in chat applications. Each frame carries a small WebSocket header plus the "Broadcast: ..." payload, roughly 25 bytes per frame, so the 5 frames together total about 125 bytes. Sending only 4 messages would require the loop to explicitly skip the sender (for example with an if (client !== ws) check), which this code does not do. Sending 25 messages would require every client to independently re-broadcast to all other clients, which nothing in this handler causes. And broadcasting to multiple clients is a standard WebSocket pattern, not a limitation of the protocol.

ExplanationREST APIs use HTTP status codes to communicate the outcome of each request. POST returns 201 Created because a new resource now exists at the given Location. GET returns 200 OK because it returns the user's JSON body. DELETE returns 204 No Content because the deletion succeeded but there is nothing left to send back — the resource is gone, so the response body is intentionally empty. When the client then sends GET /api/users/42, the server looks up user 42 in the database, finds no matching record because it was just deleted, and returns 404 Not Found. This second status code is the proof that the deletion was real and persisted: if DELETE had merely acknowledged the request without actually removing the record, the follow-up GET would still return 200 OK with the user's data. Instead it returns 404, showing the record is genuinely gone from storage, not just missing from the DELETE response body itself.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan users (10000 rows) and orders (50000 rows). (2) INNER JOIN: match on user_id; with orders distributed uniformly across users, 50000 orders divided by 10000 users gives 5 matching orders per user on average, so the join produces 50000 row combinations. (3) GROUP BY users.name: collapses these 50000 joined rows back into 10000 groups, one per user. (4) HAVING SUM(amount) > 500: filters those 10000 groups, keeping only the ones whose order total exceeds 500. The final output therefore contains only that filtered subset of groups — not the raw 50000 join rows, not the unfiltered 10000 groups, and not all 10000 users as would happen if HAVING were skipped.

ExplanationThe FROM clause scans products (5000 rows) and reviews (25000 rows), and the LEFT JOIN matches them on product_id, producing at most 5000 × 25000 combinations in the worst case, though in practice each product only combines with its own matching reviews. GROUP BY products.name then collapses every matched row down to one row per distinct product name, so at most 5000 groups exist after this step — products with no matching reviews still form their own group, but AVG(reviews.rating) evaluates to NULL for them. HAVING AVG(rating) > 3.5 then filters these groups: since NULL > 3.5 is never true, reviewless products are dropped, and only groups whose average rating genuinely exceeds 3.5 remain. Because HAVING only ever removes groups and never creates new ones, the final row count is bounded between 0 and 5000 — the precise number cannot be pinned down from the two table sizes alone, since it depends on the actual distribution of rating values.

ExplanationThe subquery (SELECT AVG(marks) FROM Students) runs first and independently of the outer query, computing the average of all five marks: (78 + 92 + 65 + 88 + 74) / 5 = 397 / 5 = 79.4. Because this is an uncorrelated subquery, it is evaluated once and its scalar result (79.4) is substituted directly into the WHERE clause, giving WHERE marks > 79.4. The outer query then checks each row: Aarav (78) fails since 78 < 79.4; Bhavya (92) passes; Chirag (65) fails; Divya (88) passes; Esha (74) fails. So the result contains exactly two names: Bhavya and Divya. A scalar subquery (one that returns a single value) never needs ANY or ALL — those keywords are only required when a subquery can return multiple rows — and a subquery is free to select from the same table the outer query is querying, since it is evaluated as a completely separate, independent step before the outer WHERE clause runs.

ExplanationSQL executes in this logical order: FROM/JOIN first, then GROUP BY, then HAVING. In the FROM/JOIN step, because grades.student_id is a foreign key referencing students, each of the 15000 grades rows matches exactly one student row, contributing exactly 15000 joined rows. Because this is a LEFT JOIN, any student row with zero matching grades rows is still kept, with NULLs in place of the grade columns — and each such unmatched student contributes one extra row that is not part of the 15000 count. So the total joined row count is at least 15000, and strictly greater than 15000 whenever any of the 3000 students has no grades at all; it is never capped at 15000. Next, GROUP BY students.name consolidates the joined rows into at most 3000 groups, one per distinct student. Finally, HAVING AVG(score) > 85 discards any group whose average score does not exceed 85, so the query's output is a subset of at most 3000 rows — only the students whose average grade clears the threshold.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan customers (8000 rows) and transactions (100000 rows). (2) INNER JOIN on customer_id: since customer_id identifies a single customer, each of the 100000 transaction rows matches at most one customer row, so the join produces up to 100000 rows — bounded by the transactions table, not by the product of both table sizes. (3) GROUP BY customers.name: collapses the joined rows into at most 8000 groups, one per customer. (4) HAVING COUNT(total) > 10: keeps only the groups whose transaction count exceeds 10, discarding customers with 10 or fewer transactions. On average each customer has 100000/8000 = 12.5 transactions, so a meaningful share of groups will satisfy the HAVING condition, but the exact result size depends on how unevenly transactions are distributed across customers.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan articles (1000 rows) and comments (50000 rows). (2) LEFT JOIN on article_id: comments is the many side of the one-to-many relationship, so the join is bounded by its row count — at most 50000 combined rows. (3) GROUP BY articles.name collapses these joined rows into at most 1000 groups, one per distinct article name. (4) HAVING SUM(likes) > 100 discards any group whose total likes do not exceed 100. Therefore the final output contains at most 1000 rows, and could be as few as 0 if no article's comments total more than 100 likes.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan warehouses (200 rows) and inventory (40000 rows). (2) RIGHT JOIN on warehouse_id: since inventory is the right table, all 40000 inventory rows are preserved in the join output, each matched to its warehouse — with a uniform distribution that is 40000/200 = 200 matching rows per warehouse, so the join produces up to 40000 row combinations. (3) GROUP BY warehouses.name: collapses those 40000 joined rows into 200 groups, one per warehouse. (4) HAVING SUM(quantity) > 5000: filters those 200 groups down to only the ones whose total quantity exceeds 5000. The final result therefore contains only the groups meeting that threshold — not all 200 warehouses, and not the full 40000-row join output.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan flights (5000 rows) and bookings (80000 rows). (2) INNER JOIN: match rows on flight_id, producing up to 5000 x 80000 = 400000000 row combinations in the worst case before any grouping happens. (3) GROUP BY flights.name: collapses the joined rows into at most 5000 groups, one per distinct flight. (4) HAVING MIN(bookings.price) > 299: this runs after grouping and keeps only those groups whose minimum price exceeds 299, discarding the rest. Therefore the final output is a subset of the 5000 groups — specifically, only the groups that satisfy the HAVING condition — not the full join output and not all 5000 flights.

ExplanationStep-by-step SQL execution: (1) FROM clause reads hospitals (300 rows) and patients (200000 rows). (2) LEFT JOIN matches hospitals.hospital_id to patients.hospital_id; in the theoretical worst case, if every patients row matched every hospitals row, the join could produce up to 300 x 200000 = 60000000 row combinations (in practice far fewer, since only matching rows are joined). (3) GROUP BY hospitals.name then collapses the joined rows into at most 300 groups, one per hospital, since hospitals.name is the grouping key and hospitals has only 300 rows. (4) HAVING COUNT(patients.visits) > 500 is applied after grouping (HAVING always runs after GROUP BY, never before), keeping only the groups whose aggregated visit count exceeds 500. So the final result is a subset of those 300 groups: exactly the hospitals whose total visit count passes the threshold.

ExplanationStep-by-step SQL execution: (1) FROM clause: scan courses (500 rows) and enrollments (30000 rows). (2) INNER JOIN: each enrollments row has one matching courses row via the course_id foreign key, so the join produces exactly 30000 row combinations, not a cross product of 500 × 30000. (3) GROUP BY courses.name: collapses the 30000 joined rows into at most 500 groups, one per course that has at least one enrollment. (4) HAVING AVG(grade) > 78: keeps only the groups whose average grade exceeds 78, dropping the rest. Therefore the final result contains only the groups meeting the threshold condition, not all 500 courses.