Grade 9 AI & Computer Science Practice Questions — Set 8

ExplanationThis is a textbook case of Simpson's Paradox, and it is exactly the trap causal inference is designed to catch: aggregating across groups without accounting for a confounder can flip the apparent direction of an effect. Within the Easy track, Method A's 93.1% pass rate (81/87) beats Method B's 86.7% (234/270). Within the Hard track, Method A's 73.0% (192/263) still beats Method B's 68.8% (55/80). Method A wins in both strata, every time it is compared like-for-like. Yet Method A's overall pass rate (273/350 = 78.0%) looks lower than Method B's (289/350 = 82.6%) — because track difficulty independently lowers pass rates for everyone and simultaneously determines which method a student was likely to receive: strugglers were pushed toward Method A on the Hard track, while confident students coasted through Method B on the Easy track. Comparing raw totals conflates the effect of the study method with the effect of track difficulty, so the 82.6% vs 78.0% aggregate is comparing two different populations, not two methods. Controlling for the confounder by comparing within each track is what a causal read requires, and that stratified comparison consistently favors Method A. A reversal of this kind is a known, real statistical phenomenon, not proof of bad data entry — and a lower absolute pass rate on the Hard track doesn't indict Method A specifically, since Method B's rate drops on the Hard track too; the track itself, not the method, is what is dragging both numbers down.

ExplanationThe alert rule requires two consecutive weekly readings below 94.0% (96.0% minus 2 percentage points), not a single dip and not an overall average. Week 1 (95.5%) and Week 2 (94.6%) are both still above 94.0%, so no breach has occurred yet. Week 3 (93.8%) is the first week below 94.0%, but that is only one breach — the rule needs a second consecutive week to rule out a one-off noisy week, such as a temporary payment-gateway outage or a festival-season shift in the transaction mix. Week 4 (93.5%) is also below 94.0%, giving two consecutive weeks of breach, so the drift alert is correctly confirmed and raised at the end of Week 4. Alerting already at Week 3 would fire on unconfirmed noise before the pattern is verified, and alerting at Week 2 is premature since 94.6% has not even crossed the threshold. Averaging all five weeks gives (95.5 + 94.6 + 93.8 + 93.5 + 95.1) / 5 = 94.5%, which stays above 94.0% and completely hides the real two-week drift episode in the middle of the window — this is exactly why robust drift-monitoring systems use a consecutive-window rule rather than a single long-run average that can smooth away localized drift.

ExplanationIn N-way K-shot episodic meta-learning, N is the number of classes sampled per episode and K is the number of labeled examples per class in the support set — so the support set size is N × K, not K alone. Here that's 5 × 3 = 15 images. The query set draws from the same N classes with its own count of unlabeled examples per class, so its size is N × (queries per class) = 5 × 10 = 50 images, not just the queries-per-class figure. Both sets belong to the same episode: the model briefly adapts using the 15 support images, and that adapted model is then scored on the 50 query images to produce the training signal — so one full episode contains 15 + 50 = 65 images. The 2 classes held out for the final generalization test sit entirely outside the episodic training loop; they exist to check whether the trained model generalizes to genuinely unseen classes once training is finished, so they contribute 0 images to any individual episode and must not be folded into this count.

ExplanationRecyclerView's ViewHolder pattern breaks the older assumption that a scrollable list needs one permanent View object per data item. Instead of inflating a separate View for each of the 10,000 products, RecyclerView keeps only enough View objects to cover what's physically visible (6 cards) plus a small recycling buffer (2 extra), for a total of about 8. As the user scrolls, onBindViewHolder() re-populates these same 8 View objects with new product data — image, name, price — while the old data simply scrolls off-screen and gets overwritten, not the View itself. This is precisely why RecyclerView (and ListView's convertView mechanism before it) exists: on an Android Go phone with 1GB of RAM, holding 10,000 live View objects at once would exhaust memory and crash the app, while 8 recycled views keep memory usage flat no matter how large the catalog grows. That constant, catalog-size-independent memory footprint is what "building for billions of users" actually demands — most of those users are on entry-level hardware, not flagship phones with RAM to spare.

ExplanationTrue Positive Rate (also called recall or sensitivity) is calculated as correctly shortlisted truly-capable students divided by the total number of truly-capable students in that group — not divided by the group's total size. For rural applicants that is 20 ÷ 40 = 50%; for urban applicants it is 32 ÷ 40 = 80%. Even though both groups show identical 70% overall accuracy — (20+50)/100 for rural and (32+38)/100 for urban — a truly capable rural student has only a 50% chance of being shortlisted while an equally capable urban student has an 80% chance, a 30-percentage-point gap in opportunity that the aggregate accuracy figure completely hides. This is exactly why fairness audits of real screening systems — scholarship, loan, and college-admission tools used across India included — must check group-wise error rates such as True Positive Rate and False Positive Rate separately, not just overall accuracy. Two models can post the same accuracy while delivering very different real-world outcomes to different communities, so matching accuracy numbers is not proof of fairness. Error types also do not simply cancel out: a higher false-positive rate among urban applicants does nothing to help the truly qualified rural students who were wrongly rejected. The equal-opportunity fairness criterion specifically compares True Positive Rates across groups, and here it is clearly violated.

ExplanationMotion-to-photon latency is a chain of dependent stages, not a single number set by refresh rate: the display can't scan out a frame until rendering finishes, and rendering can't start until the sensor has reported the head's new position. So the four stages here add sequentially: 2 ms (sensor + pose) + 11 ms (render) + 3 ms (buffer transfer) + 5 ms (panel switch) = 21 ms. Since the widely used comfort ceiling for motion-to-photon latency in VR is 20 ms — the point below which most users don't consciously notice the world lagging behind their head movement — this headset sits 1 ms above the line, and a sensitive user could still feel a faint disconnect between their inner ear and what they see, even at a smooth 90 Hz. A 90 Hz refresh rate only guarantees that a new frame is displayed every 11.1 ms once the pipeline is running steadily — it says nothing about how long any single frame took to travel from sensor to screen; a headset can render at a buttery 90 fps while still carrying 21 ms of accumulated pipeline lag on every frame. Rendering also can't be dropped from the total as if it ran for free in parallel: the GPU needs the tracking data before it can even start drawing, and the display needs the finished frame before it can start transferring it, so each stage waits on the one before it. And while much larger delays — nearer 50-100 ms — cause the obvious stutter people associate with a laggy game, the specific 20 ms figure (popularized by VR pioneers like John Carmack) is the accepted motion-to-photon threshold for headsets specifically; treating 50 ms as the real limit would let a genuinely uncomfortable headset pass as fine.

ExplanationThe pattern /^[6-9]\d{9}$/ has to match the entire string, not just part of it. The ^ anchor pins the very first character to the class [6-9], \d{9} then demands exactly nine more digits right after it, and the $ anchor demands the string end at that exact point — nothing before, nothing after. "9876543210" satisfies all three conditions in order: the first character is 9 (inside [6-9]), it is followed by exactly nine more digits (876543210), and the string stops there, so $ matches immediately — pattern.test() returns true. "9876543210 " fails because after the 10th digit the string still has a trailing space; $ needs the string to end right after \d{9} finishes matching, but a space character remains, so no match is found. "5987654321" fails at the very first position: 5 does not fall inside the character class [6-9], so the regex engine rejects it before it even gets to checking the remaining digits — this is the classic mistake of assuming any 10-digit number is a valid Indian mobile number instead of restricting the leading digit to 6-9. "98765432100" has 11 digits, not 10. \d{9} greedily consumes nine digits after the first one (reaching the 10th digit overall), but $ then fails because there is still an 11th digit left before the actual end of the string — an easy miscount if you only check the starting digit and total character feel rather than the exact length.

ExplanationCSS Grid's auto-fit works in two stages, and both matter here. First, the browser determines the largest number of columns that can each be at least 180px wide without the row overflowing the 1000px container, accounting for the 20px gaps between columns. For n columns there are (n − 1) gaps, so the space needed is n × 180 + (n − 1) × 20. Testing n = 5: 5 × 180 + 4 × 20 = 900 + 80 = 980px, which fits inside 1000px. Testing n = 6: 6 × 180 + 5 × 20 = 1080 + 100 = 1180px, which overflows. So only 5 columns can share the first row, and the 6th card wraps down to a new row underneath. Second, because each column is defined as 1fr rather than a fixed 180px, the leftover space (1000 − 980 = 20px) doesn't sit empty — it is shared equally across the five fr columns: 20 ÷ 5 = 4px extra per column, making each column 180 + 4 = 184px wide. Checking the total confirms it: 5 × 184 + 4 × 20 = 920 + 80 = 1000px, exactly the container's width. The frequent errors here are forgetting that minmax()'s first value is a hard floor (so columns can never shrink below 180px just to fit more items in a row), and forgetting that gap space must be subtracted before dividing the remaining width among columns.

ExplanationChrome DevTools does not convert an object into readable text the instant console.log() runs. The console entry instead stores a reference to the actual object in memory, and only renders its properties into an expandable tree when you click the disclosure triangle — which in this trace happens after cart.price has already changed from 40 to 55. Because Log A and Log B both point to the exact same object, expanding either one at that later moment shows price: 55, even though Log A was printed to the panel first, before the mutation occurred. This is precisely why experienced developers avoid logging live objects when they need to inspect state at a specific instant — they instead write console.log(JSON.parse(JSON.stringify(cart))) or console.log(structuredClone(cart)) to freeze a copy of the values before later code can change them. The assumption that console.log() snapshots everything at call time is a natural mistake carried over from how primitive values like numbers and strings behave (they are copied by value), but objects are logged by reference — so any mutation made before you actually expand the entry becomes retroactively visible, even in a log that was written earlier.

ExplanationJSON's grammar is stricter than the language features it superficially resembles, and each flawed version above breaks a different rule. The response with double-quoted keys and strings, lowercase `true`, and no dangling comma after the second passenger object parses cleanly — `JSON.parse()` or `json.loads()` returns a nested object with `pnr: "4508213967"`, `trainNumber: "12951"`, and `fare: 1495.50` intact. The version with a comma trailing the last passenger entry before `]` fails because JSON — unlike a JavaScript array literal or a Python list — never permits a trailing comma after the final element; the parser expects either another element or the closing bracket, not a comma immediately followed by `]`. The version using unquoted keys and single-quoted strings is valid JavaScript object-literal syntax but not JSON: the spec requires every key and every string value to be wrapped in double quotes, with no exception for identifier-style keys. The version with `True` for `chartPrepared` fails for a related reason — JSON defines exactly three case-sensitive literal keywords, `true`, `false`, and `null`; capitalizing the first letter turns it into a bare, unrecognized token (borrowed from Python's `True`) that no JSON parser accepts, so parsing throws a syntax error before it ever reaches the passengers array.

ExplanationWith one request permitted every 8 seconds and 450 pages to fetch, waiting the crawl-delay before every request (including the first) gives 450 x 8 = 3,600 seconds, which is 60 minutes, as the minimum time the scraper needs to finish. The pages themselves are safe to request: robots.txt lists /fare-enquiry/ under Allow and only /eticketing/ under Disallow, so the scraper is only ever touching permitted URLs. Two details are easy to get backwards here. First, a Crawl-delay value under "User-agent: *" is a site-wide throttle for that agent — it applies to every path the agent is allowed to crawl, not just the Disallowed ones; an Allow entry means "you may fetch this," not "you're exempt from the delay." Second, robots.txt is a voluntary convention read by cooperative crawlers, not a statute — India's IT Act does not make ignoring a Crawl-delay directive a criminal offence on its own. Any real legal exposure from scraping would come from other sources entirely, such as a site's Terms of Service, copyright over the content, or data-protection law governing what is later done with any personal data collected — not from the robots.txt file itself. A scraper that gets both the arithmetic and these two distinctions right is behaving efficiently and ethically at the same time.

ExplanationFive unique transactions exist in the log — T1 through T5 — but T1 and T4 each appear twice because of a retry. Grouping by txn_id and checking each group for at least one SUCCESS row gives: T1's two rows are both SUCCESS for the same retry attempt, so it contributes ₹500 exactly once; T2 has no SUCCESS row at all, so it is dropped entirely; T3 contributes ₹300; T4 has one FAILED row and one SUCCESS row — since a SUCCESS exists somewhere in the group, the transaction counts as successful and contributes its SUCCESS amount, ₹750, while the FAILED duplicate is simply ignored; T5 contributes ₹900. Adding these: 500 + 300 + 750 + 900 = ₹2,450. The most common trap is forgetting that T1's two SUCCESS rows are the same retried payment and adding ₹500 twice, which overcounts the total to ₹2,950. A second trap is assuming that any FAILED row disqualifies its whole txn_id — that logic wrongly throws out T4 even though it eventually succeeded, undercounting to ₹1,700. A third trap is summing every row in the raw log with no grouping or filtering at all, which includes T2's failed ₹1,200 along with both of T4's rows and lands on ₹4,900 — this defeats the entire purpose of the transform stage, which exists precisely to deduplicate retries and drop genuinely failed transactions before clean data reaches the dashboard.

ExplanationWork it in two stages, and round up at both. First, how many calls are needed: each call returns at most 500 records, and 8,742 ÷ 500 = 17.484. Since a call can't return a fraction of a page, this needs ceil(17.484) = 18 calls — 17 calls covering 8,500 records, plus one more call to pick up the remaining 242 records (that last call being a partial page doesn't change that it's still just one call among the 18). Second, how many minutes those 18 calls take at a cap of 12 calls per minute: 18 ÷ 12 = 1.5, which again must round up to ceil(1.5) = 2, because a minute can't be fractional either — 12 calls complete in minute one, and the remaining 6 calls complete during minute two. Rounding 1.5 down to 1 minute (as in one distractor) ignores that those last 6 calls still need server time; treating the rate limit as "about one call per minute" (as in another) misreads what "12 calls per minute" means; and giving the partial last page its own separate minute (as in the third) double-counts a call that's already included in the 18.

ExplanationBuilding the adjacency list from the track segments gives A: {B, C}, B: {A, D, E}, C: {A, F}, D: {B}, E: {B, F, G}, F: {C, E}, G: {E}. Following alphabetical order at every branch, DFS starts at A and immediately dives into B (A's earliest neighbour). From B, D comes before E alphabetically, so D is visited next; D has no unvisited neighbours, so the search backtracks to B and moves on to E. From E, F comes before G, so F is visited next. F's neighbours are C and E; E is already visited, so C — reached only through this F branch, even though it is also a direct neighbour of A — gets visited here, at position six. Only after this entire branch is exhausted does the search backtrack all the way up to E and finally pick up G, the one remaining unvisited neighbour. This produces A, B, D, E, F, C, G. The sequence A, B, C, D, E, F, G is what breadth-first search produces on this same graph, since BFS visits every neighbour of a station before going deeper into any of them — DFS instead commits to one branch and exhausts it fully before trying another. The sequence A, B, D, E, G, F, C comes from breaking the tie-break rule at E by visiting G before F, even though F is alphabetically earlier. The sequence A, B, D, E, C, F, G comes from jumping straight to C right after E, as if C's direct edge back to A gives it priority — but DFS never returns to A's second neighbour until every station reachable through the first branch, including C (reached via F), has already been visited.

ExplanationKruskal's algorithm sorts every link by cost and adds each one only if it doesn't close a cycle. Sorted by cost, the links here are S–U (₹2L), R–S (₹3L), P–Q (₹4L), Q–R (₹5L), S–T (₹6L), T–U (₹7L), R–T (₹8L), P–R (₹9L), Q–S (₹10L). The first five of these — S–U, R–S, P–Q, Q–R, S–T — connect all six control rooms without ever forming a cycle, so they make up the tree, giving the stated ₹2L + ₹3L + ₹4L + ₹5L + ₹6L = ₹20 lakh. Once S–T is ruled out, T has no remaining connection to the rest of the network at all — it must be reconnected through whichever of its other links is cheapest and doesn't create a cycle. T's remaining links are T–U (₹7 lakh) and R–T (₹8 lakh); T–U is the cheaper of the two, so it takes S–T's place. The rest of the tree (S–U, R–S, P–Q, Q–R) is untouched because none of those links depended on S–T. The new total is ₹2L + ₹3L + ₹4L + ₹5L + ₹7L = ₹21 lakh, exactly ₹1 lakh more than before — matching the ₹1 lakh gap between S–T's cost and T–U's cost. Using R–T instead gives a valid spanning tree too, but at ₹22 lakh it isn't the cheapest one, so it's not minimum. The cost can't stay at ₹20 lakh, because S–T was actually load-bearing — it was the only link touching T in the original tree, so losing it forces a real replacement cost. And adding both T–U and R–T would give T two links into the tree, which isn't a spanning tree at all: a spanning tree connects every new node through exactly one edge, with zero redundancy by definition.

ExplanationTrace each insertion using the BST rule (smaller goes left, larger goes right, starting the comparison at the root each time). 42 becomes the root. 23 < 42 goes left of 42; 68 > 42 goes right of 42. 15 < 42 then < 23 becomes the left child of 23; 30 < 42 then > 23 becomes the right child of 23. 55 > 42 then < 68 becomes the left child of 68; 81 > 42 then > 68 becomes the right child of 68. 4 < 42, < 23, < 15 becomes the left child of 15. 19 < 42, < 23, > 15 becomes the right child of 15. 27 < 42, > 23, < 30 becomes the left child of 30. The finished shape is: root 42; level 1 has 23 and 68; level 2 has 15, 30, 55, 81; level 3 has 4, 19 (under 15) and 27 (under 30), while 55 and 81 are leaves at level 2. Counting edges from the root to the deepest nodes (4, 19, or 27) gives 42-23-15-4, which is 3 edges, so the height is 3. Plain BSTs (unlike AVL or red-black trees) never self-balance on their own, which rules out the "self-balances" claim; counting 4 as the height confuses total levels of nodes with edge-count height and also wrongly assumes every ten-node BST fills four full levels, which only happens for a perfect tree of 15 nodes, not this one; and the tree is not a fully skewed chain because the arrival order 42, 23, 68, ... sends values to both left and right subtrees rather than always the same side, so a height of 5 would require a much more lopsided insertion order than the one given.

ExplanationThe defining test from Mitchell's definition is not "does the system use data" but "does its performance at a task automatically improve as experience grows, without a human rewriting the logic." Priya's system passes this test on all three counts: the experience E is the 2-lakh-transaction labelled history, the task T is classifying a transaction as fraud or genuine, and the performance measure P is accuracy — which climbed from 82% to 94% purely because the decision-tree algorithm re-learned patterns from a larger dataset each month, with no rule hand-edited. Arjun's system fails because the ₹50,000/1 AM–4 AM/new-UPI-ID thresholds are permanently fixed by a human programmer; no matter how many transactions flow through it, the logic never adapts, so it is traditional rule-based programming, not learning. Rohit's system fails because it performs no prediction task at all — every fraud/genuine label is assigned by a human officer, and the dashboard merely counts and sorts those human decisions, so there is no P being improved by the software itself. Meera's blocklist is the subtlest trap: it looks data-driven because it references 500 real scammer IDs, but the list only grows because her compliance team manually types in new entries each week. The system's own accuracy at catching new, previously unseen scammers never improves on its own — the improvement comes from human labour, not from a learning algorithm processing experience, so it is an expert-style lookup table rather than machine learning.

ExplanationSumming all 10 readings — 28+29+27+30+28+29+0+28+27+29 — gives 255, so the uncorrected mean is 255 ÷ 10 = 25.50°C. The stuck sensor's 0°C contributes nothing to that sum, but it does count toward the divisor, so it silently pulls the average down even though a genuinely broken sensor should not influence the result at all. Cleaning means removing that sensor's reading from the dataset entirely — not just from the sum but from the count of readings being averaged. The 9 remaining valid readings still sum to 255 (since the 0 added nothing), but now 255 ÷ 9 = 28.33°C. The two means differ by 28.33 − 25.50 = 2.83°C, and this whole 2.83°C gap exists purely because one faulty sensor was left in the calculation — nothing about the real campus temperature changed. This is the core "Garbage In, Garbage Out" lesson: a single unfiltered bad reading, even 1 out of 10 data points, can shift a summary statistic by several degrees, and any ML model trained on the uncorrected data would learn a systematically colder, wrong picture of the campus. The most common cleaning mistake is remembering to zero out the bad value's contribution to the sum but forgetting to shrink the count of readings being divided by — that error, dividing 255 by 10 instead of 9, is exactly what produces a false "no difference" result.

ExplanationTrace the 1-NN rule by hand. In Way 1, every one of the 6 training students is compared against the full training set — including itself. Since all six hours-studied values (1, 3, 6, 7, 10, 12) are distinct, each student's own record is always the closest match, at a distance of 0 hours, so the model simply reads back that student's own true result. That makes Way 1 a perfect 6-out-of-6, or 100% — but this number says nothing about the model's real ability to predict new students, because the "test" data was already sitting inside the training set. Way 2 is the honest test: for a 5-hour student, the distances to the six training hours are 4, 2, 1, 2, 5, and 7 hours, so the closest match is the 6-hour student (distance 1), labelled Pass — matching the 5-hour student's actual Pass, a correct prediction. For a 9-hour student, the distances are 8, 6, 3, 2, 1, and 3 hours, so the closest match is the 10-hour student (distance 1), labelled Pass — but the 9-hour student actually Failed, so this prediction is wrong. That gives 1 correct out of 2, or 50%, in Way 2. The 50-point gap between the 100% and the 50% is exactly why evaluating a model on its own training data is like letting a student grade their own exam with the answer key already memorised: it always looks perfect, while a genuinely unseen test set reveals the model is just copying the nearest label rather than learning the real relationship between hours studied and passing.

ExplanationCompute the Euclidean distance from the query (500, 3) to every training point using distance = √((Δamount)² + (Δcomplaints)²). P1 (500, 1): Δ = (0, −2) → √(0² + 2²) = √4 = 2.00 P5 (510, 5): Δ = (10, 2) → √(10² + 2²) = √104 ≈ 10.20 P2 (520, 4): Δ = (20, 1) → √(20² + 1²) = √401 ≈ 20.02 P3 (480, 0): Δ = (−20, −3) → √(20² + 3²) = √409 ≈ 20.22 P4 (5000, 1): Δ = (4500, −2) → distance ≈ 4500.00 Ranking these five distances gives P1 (2.00) < P5 (10.20) < P2 (20.02) < P3 (20.22) < P4 (4500.00). With k = 3, the three closest points are P1, P5, and P2 — labelled Legit, Fraud, Fraud. Majority vote is 2 Fraud to 1 Legit, so the classifier predicts Fraud. The near-miss between P2 (≈20.02) and P3 (≈20.22) is the trap: swapping them — picking P1, P5, P3 instead of P1, P5, P2 — flips the vote to Legit, which is exactly the arithmetic slip a rushed calculation produces. But 20.02 is genuinely smaller than 20.22, so P2 belongs in the neighbourhood, not P3. There is also no real tie to justify raising k — 20.02 and 20.22 differ, they're merely close, and "closer" is well-defined the moment you compute both distances precisely. And KNN doesn't let one feature override the distance calculation by fiat; every feature enters the same sum of squares (this is exactly why unscaled features with very different numeric ranges — like Rs 500 versus a 0–5 complaint count — need normalization in real systems, since a large-range feature can dominate distance regardless of how predictive it actually is).