Grade 9 AI & Computer Science Practice Questions — Set 9

ExplanationNaive Bayes assumes the two bigram features are conditionally independent given the class, so each class's unnormalized score is prior × likelihood('ka') × likelihood('th'). For Hindi: 0.5 × 0.8 × 0.3 = 0.12. For English: 0.5 × 0.2 × 0.6 = 0.06. These raw products are not yet probabilities — Naive Bayes converts them into one by dividing each by their sum, 0.12 + 0.06 = 0.18. That gives P(Hindi | data) = 0.12 / 0.18 = 2/3 ≈ 66.7% and P(English | data) = 0.06 / 0.18 = 1/3 ≈ 33.3%. Since 66.7% is the larger posterior, the classifier predicts Hindi with confidence 66.7%. The other outcomes correspond to real bugs students hit when coding this by hand: reading the 'ka' likelihood column from the wrong class (swapping 0.8 and 0.2) flips the prediction to English at ≈88.9%; replacing multiplication with addition — treating the score as prior + likelihood + likelihood instead of prior × likelihood × likelihood — produces a spurious 1.6/2.9 ≈ 55.2%; and forgetting the final normalization step, reporting the raw product 0.12 as though it were already a probability, understates Hindi's confidence as 12% instead of 66.7%. Watching out for these three failure modes — correct class-to-column mapping, multiplicative (not additive) combination of independent likelihoods, and always renormalizing at the end — is exactly what separates a working Naive Bayes language detector from a buggy one.

ExplanationThe key thing to trace is what `await` actually does inside a loop. When the engine hits `await` inside `getWeather`, it suspends `loadDashboard` at that exact line and does not move to the next loop iteration until the awaited promise settles. So the three calls do not overlap — Mumbai's 3000ms timer must finish before Delhi's `getWeather` call even starts, and Delhi's 1000ms timer must finish before Chennai's starts. The total wall-clock time is therefore the sum of the delays: 3000 + 1000 + 2000 = 6000ms, and the console log order is Mumbai fetching, Mumbai done, Delhi fetching, Delhi done, Chennai fetching, Chennai done — strictly in sequence. This is a genuinely easy mistake to make because `Promise.all([getWeather("Mumbai",3000), getWeather("Delhi",1000), getWeather("Chennai",2000)])` really would start all three timers together and finish in ~3000ms (the largest single delay) — but that only happens when the promises are created and handed to `Promise.all` up front, not when `await` sits inside a sequential loop body. JavaScript's event loop doesn't reorder or average timers by duration either; `setTimeout` delays are honored as written, they're just not blocking the rest of the program the way a synchronous sleep would be. And `console.time`/`console.timeEnd` measure real elapsed wall-clock time between the two calls, including time spent suspended on `await` — they are not restricted to synchronous execution, which is exactly why this pattern is a common performance bug in real full-stack weather dashboards: fetching each city's data one at a time when they could all be requested in parallel with `Promise.all`.

ExplanationIn JavaScript, a variable declared with var is function-scoped, not block-scoped, unlike let. That means the for loop does not create a fresh i for each pass -- all three addEventListener calls attach closures that reference the exact same i variable sitting in memory. None of those closures run during the loop itself; they only execute later, whenever a user actually clicks a button. By the time the loop condition i < buttons.length is checked and finally fails, i has already been incremented to 3 (since buttons.length is 3), and the loop exits leaving i permanently at that value. So when the student clicks the second button (index 1), the handler doesn't read the index the button was created with -- it reads whatever i currently equals, which is 3 for every single button. This is exactly why modern DOM event-handling code favors let over var inside loop counters: let creates a new, block-scoped binding of i on every iteration, so each closure correctly locks in its own index (0, 1, or 2) instead of all three sharing one leftover value.

ExplanationSass gives every pair of curly braces its own variable scope. When $color: red; appears as the first statement inside .card { }, it does not overwrite the global $color: blue; instead it creates a new variable named $color that is local to the .card block (this has been Sass's behavior since version 3.4, precisely to stop nested reassignments from leaking outward — a reassignment only reaches the outer scope if you add the !global flag). Both &:hover and .title are nested inside .card, so when their color: $color; lines are compiled, Sass looks up the scope chain starting from where the rule is written and finds the local red before it ever needs to check the global scope. That's why the compiled CSS is .card:hover { color: red; } and .card .title { color: red; }. The .footer rule sits outside .card entirely, so its lookup for $color never sees the local red — it resolves directly to the untouched global value, giving .footer { color: blue; }. Only two of the three selectors end up red; the third stays blue.

ExplanationWork through each binding in the pattern left to right, exactly as the JS engine does. `passenger: { name: travellerName, age = 18 }` pulls `passenger.name` ("Aditi") into a differently-named variable `travellerName`, and pulls `passenger.age` (14) into `age`. Since `age` already exists on the object with value 14, its default of 18 is skipped entirely — defaults only fire when the extracted value is `undefined`, whether that's because the property is missing or because it's explicitly set to `undefined`. `fare: { base, gst = 50, total = base + gst }` pulls `fare.base` (850) into `base`. `fare.gst` is 42, a real value, so the `= 50` default is skipped and `gst` becomes 42. `fare.total` does not exist anywhere on `ticket.fare`, so its default expression runs. Crucially, destructuring binds names in order, so by the time `total`'s default is evaluated, `base` (850) and `gst` (42) are already live local variables — `total` becomes 850 + 42 = 892, not some fixed fallback number. `quota = "GENERAL"` sits at the top level of the pattern. `ticket` has no `quota` key at all, so accessing it also yields `undefined`, which triggers the default just as reliably as an explicitly-`undefined` property would — a missing key and an `undefined` value are indistinguishable to destructuring. So the log statement prints `Aditi 14 892 GENERAL`. The variant with age 18 wrongly assumes defaults override any present value rather than only `undefined`; the variant with `undefined` for quota wrongly assumes defaults don't cover keys that are absent from the object; and the variant with total 850 wrongly treats the default expression as copying `base` alone instead of evaluating `base + gst`.

ExplanationJavaScript class bodies always execute in strict mode, and regular methods like increment live on Counter.prototype — they are not tied to any particular instance until called with a receiver. Destructuring { increment, incrementArrow } = c pulls increment out as a bare function reference, severing its connection to c. Calling it as increment() supplies no receiver, so inside the function this is undefined (strict mode never falls back to the global object the way sloppy-mode calls do). The line this.count++ then tries to read .count off undefined, and JavaScript throws a TypeError immediately — while evaluating the argument to console.log, before console.log itself ever runs. That exception is uncaught, so execution halts right there; the second statement, which calls incrementArrow(), never executes at all. Had it been reached, incrementArrow would have worked correctly no matter how it was extracted, because arrow functions declared as class fields capture this lexically at the moment each instance is built — effectively giving every instance its own pre-bound copy of the function — unlike prototype methods, which only receive a this value when invoked through an explicit receiver such as c.increment(). This gap between auto-bound arrow class fields and receiver-dependent prototype methods is exactly why passing a class instance's methods around as callbacks (event handlers, .then() callbacks, array callbacks) is a classic source of "cannot read properties of undefined" bugs in real applications.

ExplanationThe spread operator `{...trip}` performs a **shallow** copy — it copies the object's own properties exactly one level deep. For a primitive like `destination` (a string), this means `updatedTrip` gets its own independent slot: overriding it to `"Leh"` never touches `trip.destination`, which stays `"Manali"`. But `costs` and `days` are reference types (an object and an array). Spread copies the *reference* to them, not the data they hold — so `updatedTrip.costs` and `trip.costs` point to the exact same object in memory, and `updatedTrip.days` and `trip.days` point to the exact same array. So when the code runs `updatedTrip.costs.hotel = 6000`, it mutates that one shared object, and `trip.costs.hotel` becomes `6000` too. Likewise, `updatedTrip.days.push(4)` mutates the shared array, so `trip.days.length` becomes `4`. The printed result is therefore `6000 4 Manali`. This is exactly why spread is often mistaken for a deep-copy tool — it isn't. To make nested data independent as well, you'd need to spread those levels explicitly, e.g. `{...trip, costs: {...trip.costs}, days: [...trip.days]}`.

ExplanationThe key nuance the fetch API tests here is what actually counts as a "failure" from the browser's point of view. fetch() only rejects its promise on network-level problems -- no internet connection, a DNS lookup failure, or a CORS block -- because those are cases where the browser never got a response at all. A 404 is not one of those cases: the server was reachable and sent back a complete, valid HTTP response (it just happens to be carrying a "not found" message). So fetch() resolves successfully, handing the first .then() a Response object where response.ok is false and response.status is 404. Because response.ok is false, the code runs `throw new Error(\`Status: ${response.status}\`)`, producing an Error whose message is the string "Status: 404". A throw executed synchronously inside a .then() callback does not crash the script or need to be manually wrapped in Promise.reject() -- the Promise machinery automatically catches it and converts the chain's promise into a rejected one. That rejection skips the second .then(data => console.log(data)) entirely (so the raw JSON error body never reaches console.log) and lands directly in .catch(), where error.message is "Status: 404". The call `console.error("Error:", error.message)` then prints "Error: Status: 404" to the console. The distractors describe real but mismatched behaviors: fetch() auto-rejecting on 4xx/5xx status codes is how libraries like axios behave, not native fetch, which is exactly why the manual `if (!response.ok) throw ...` check is standard practice; response.json() only ever runs if that check is passed and the value is explicitly returned, so it cannot be reached once the throw fires; and a synchronous throw inside a .then() callback is a well-defined part of the Promise spec that does produce a rejection, so the script does not crash uncaught.

ExplanationOver a 10-minute (600-second) window, HTTP polling issues one request every 3 seconds, so a single client sends 600 ÷ 3 = 200 requests. Each request-response pair carries about 700 bytes of overhead regardless of what data it carries, giving 200 × 700 = 140,000 bytes of pure overhead. A WebSocket client instead pays a single 400-byte handshake to open the connection, and after that the server only sends a tiny frame when the train's status genuinely changes — 4 times per minute for 10 minutes is 40 frames, each with 2 bytes of overhead, adding 80 bytes. Total WebSocket overhead is 400 + 80 = 480 bytes, so the saving is 140,000 − 480 = 139,520 bytes per client. The wrong totals come from three specific misreadings of how WebSockets actually work. One drops the handshake's own 400-byte cost and compares polling only against the 80-byte frame total, which overstates the saving. Another assumes the server keeps pushing on the same fixed 3-second clock as polling instead of only when the status actually changes, undercounting how much is saved. The last, and most fundamental, mistake assumes every pushed update needs its own fresh handshake the way every polling request does — but the entire point of a WebSocket is that one handshake upgrades the connection a single time, and it then stays open for as many messages as needed without repeating that cost.

ExplanationA service worker's own lifecycle is separate from the caches it manages. When the browser detects a byte-different sw.js, it installs the new version alongside the old one — the v2 worker runs its install handler, opens 'irctc-tracker-v2', and successfully caches the three files. But a freshly installed worker does not automatically take over: it sits in the "waiting" state as long as any open tab is still being controlled by the currently active worker (v1). A same-tab refresh does not remove that control, because the navigating tab is still counted as an existing client of v1 throughout the reload; the old worker keeps intercepting fetch events and keeps serving whatever caches.match() finds, which is still cache 'irctc-tracker-v1' since v1's activate handler never ran to delete it. Only when every tab controlled by v1 is fully closed (so zero clients remain) does the browser retire v1, activate v2, and let v2's activate handler delete the stale v1 cache — or the developer can force this immediately by calling self.skipWaiting() in the install handler and clients.claim() in the activate handler. The HTTP-cache explanation is wrong because Cache Storage (used here via the Cache API) is a separate, explicitly-versioned store that the developer fully controls with cache.delete(), independent of ordinary HTTP caching rules. The "permanent lock" claim is wrong because cache-first only means "prefer cache over network for a given request"; it says nothing about whether a new worker version can ever be installed with new files. The claim about activate deleting files before install finishes is wrong because the browser's service worker lifecycle strictly serializes these phases — activate for a given worker cannot begin until that same worker's install phase (and its waitUntil promise) has completed, and in this case v2's activate cannot run at all until v2 becomes the active worker in the first place.

ExplanationExpress processes a request by walking its middleware stack top to bottom, in the order things were registered — and next() only ever advances to whatever comes next in that same stack, not to some special "global middleware" category. The first app.use() has no path, so it matches every request; it logs 'A' and calls next(). Control then reaches app.get('/order', ...), which was registered with two handler functions for the same route — Express treats these as a mini-chain executed in the order they were passed. The first one logs 'B' and calls next(); since there is nowhere else to go except the next function in that same route's chain, control passes to the second handler, which logs 'C' and calls res.send('Done'). Once res.send() fires, the response has been sent and the request-response cycle is complete — Express does not continue walking further down the stack afterward. The final app.use(), which would log 'D', was registered after the /order route and is only reached if a request falls through without a response being sent (for example, a request to some other path, or a handler that calls next() instead of ending the response). Because C ends the cycle with res.send() instead of calling next(), 'D' is never printed for this request. So the console shows exactly A, B, C, in that order — nothing more, nothing less.

ExplanationHMAC-SHA256 in a JWT signs the exact string formed by concatenating the base64url-encoded header and payload with a dot between them — not just the header, and not the raw JSON before encoding. So when Priya edits the payload's role field and re-encodes just that segment, the string the server recomputes the signature over is now different from what was originally signed, and HMAC-SHA256 guarantees that even a single changed character produces an unrelated, unpredictable output. Since Priya left the original signature segment untouched, the server's freshly computed signature won't match it, and verification fails outright — the server rejects the token instead of granting admin access. This also resolves two mix-ups baked into the wrong choices. First, HS256 tokens are not encrypted: base64url is a reversible encoding that anyone can decode without any key, which is exactly how Priya was able to read and edit the role field in the first place — there is no "private key decryption" step happening on read. Second, base64url decoding performs no tamper-detection of its own; a corrupted or edited payload still decodes cleanly into valid-looking JSON, so the decoder itself never flags anything as corrupted. The only mechanism actually catching Priya's edit is the HMAC-SHA256 signature comparison over the full header-and-payload string, which is why real systems must verify that signature on every request rather than trusting whatever role value sits in the decoded payload.

ExplanationCORS is a restriction on what the browser lets JavaScript read, not a filter on what leaves the browser — so this GET request, cookie and all, genuinely reaches api.irctc-demo.in, and the server genuinely sends its response back across the network. The blocking happens afterward, when the browser checks the response headers before releasing the body to fetch()'s caller. Because credentials: "include" was used, the request is "credentialed," and the CORS spec explicitly disallows Access-Control-Allow-Origin: * in that case: a wildcard means "any website on the internet may read this," which is unsafe to combine with cookie-authenticated data like someone's train bookings. Access-Control-Allow-Credentials: true doesn't rescue the wildcard — it has no effect unless Access-Control-Allow-Origin names the exact origin. So the browser throws a CORS error and the fetch() promise rejects, even though the server did its job correctly. The fix on the backend is to read the incoming Origin header and reflect that exact value, e.g. Access-Control-Allow-Origin: https://book.irctc-demo.in, rather than using *.

ExplanationA CSRF token only works as a defense if an attacker's page cannot read its value — and the Same-Origin Policy is exactly what normally stops a script on evil-site.com from fetching learnIndia.in's HTML and pulling that hidden field out. Stored XSS breaks this guarantee in a way SOP was never designed to stop: the malicious `<script>` the attacker planted in the comment box is served back to the victim from learnIndia.in itself, so the browser treats it as first-party, same-origin code with full access to the page's DOM, cookies, and any active session. The script can simply read `document.querySelector('[name=csrf_token]').value`, then fire an authenticated `fetch('/change-password', {method:'POST', credentials:'include', body:...})` using that exact token — the server sees a perfectly valid, correctly-tokened request and processes it, even though the victim never intended to change their password. This is precisely why security engineers treat XSS as more dangerous than CSRF alone: a single unsanitized rendering point can quietly unlock every CSRF-protected form on the page. The token is not bound to the visitor's IP address (sessions and users routinely share or change IPs, especially on mobile data), and it does not expire or get reused merely because a script is present on the page — expiry is checked independently by the server. Nor does a stored payload gain any special "elevated" execution privileges; it runs with exactly the same DOM and network access as any other script the page would legitimately load, which is already more than enough to steal and replay the token.

ExplanationA token bucket holds a maximum of `capacity` tokens and gains `refillRate` new tokens every second; a request is accepted only if at least one token is present, in which case it consumes one token, and it is rejected (HTTP 429) otherwise. At t = 0 the bucket is full with 20 tokens, so exactly the first 20 requests in the burst each find a token available and are accepted, draining the bucket to 0. The remaining 15 requests arrive to an empty bucket and are rejected immediately — the bucket's capacity caps burst size, so it can never absorb all 35 at once. Once empty, the bucket needs only a single token — not a full refill to 20 — before the next request can succeed, and at a refill rate of 4 tokens/second that single token takes 1 / 4 = 0.25 seconds (250 ms) to arrive. Waiting for a full 20-token refill would take 20 / 4 = 5 seconds, but that overshoots what's needed: the very next request only requires 1 token, not a completely restocked bucket. The 4-accepted-then-1-second-wait picture instead describes a fixed-window counter that resets once per second, not a token bucket, which is exactly why it's a classic point of confusion — a token bucket lets bursts through up to its capacity and then throttles smoothly token-by-token, rather than admitting a flat 4 requests every clock second.

ExplanationEach comparison in a balanced B-tree (or binary search) index eliminates half of the remaining candidate records, so the search size shrinks as 1,048,576 → 524,288 → 262,144 → 131,072 → ... → 2 → 1. Counting those halving steps: since 2^20 = 1,048,576 exactly, it takes precisely 20 halvings — and therefore 20 comparisons — to narrow the full table down to the single matching PNR record. An unindexed linear scan has no such shortcut: it must check records one at a time, so its worst case is the full 1,048,576 comparisons, not a reduced figure. The 524,288 figure describes the average case for an unindexed linear scan (checking half the table before finding a match on average) — it is not how an index behaves, and confusing the two is a common mix-up between "index lookup" and "average-case brute-force search." The 21 figure is an off-by-one slip: once repeated halving has narrowed the candidates down to a single record, that record has already been found — no extra comparison beyond the 20 halving steps is needed. This logarithmic-versus-linear gap is exactly why indexes matter on large real-world tables: an IRCTC PNR lookup or a UPI transaction search that would take over a million comparisons unindexed can complete in about 20 comparisons with a proper index, which is the practical difference between an instant response and a system that visibly lags.

ExplanationAn INNER JOIN doesn't match one row to one row — for each value of passenger_id, it pairs every matching row in BOOKINGS with every matching row in PAYMENTS, so the row count multiplies within each group rather than adding. P1 appears twice in BOOKINGS (B101, B102) and twice in PAYMENTS (U201, U202), so the join produces 2 × 2 = 4 combined rows for P1: (B101,U201), (B101,U202), (B102,U201), (B102,U202). P2 appears once in each table, contributing 1 × 1 = 1 row. P3 appears in BOOKINGS but has no row in PAYMENTS at all, so INNER JOIN — which only keeps rows with a match on both sides — drops B104 entirely rather than keeping it with NULLs, since that padding behaviour belongs to a LEFT JOIN, not an INNER JOIN. Adding the groups together: 4 + 1 + 0 = 5 rows total. The trap here is treating a join like a simple lookup that returns at most one row per input row; whenever the join key has duplicates on both sides, the result set grows by multiplication, which is exactly why real-world queries on tables with repeated foreign keys can unexpectedly explode in size.

ExplanationFor this data, n = 4, Σx = 2+4+6+8 = 20, Σy = 40+45+60+65 = 210, Σxy = (2·40)+(4·45)+(6·60)+(8·65) = 80+180+360+520 = 1140, and Σx² = 4+16+36+64 = 120. The slope is b = (4·1140 − 20·210) / (4·120 − 20²) = (4560 − 4200) / (480 − 400) = 360/80 = 4.5. The mean values are x̄ = 20/4 = 5 and ȳ = 210/4 = 52.5, so the intercept is a = ȳ − b·x̄ = 52.5 − 4.5·5 = 52.5 − 22.5 = 30, giving the fitted line y = 4.5x + 30. Substituting x = 10 gives y = 4.5(10) + 30 = 45 + 30 = 75 marks. 70 marks comes from extending only the slope between the last two points, (6, 60) and (8, 65) — a slope of (65−60)/(8−6) = 2.5 marks per hour — two more hours past x = 8 gives 65 + 2.5×2 = 70. This treats a local trend between adjacent points as if it were the overall regression slope, but the least-squares line is fitted using every point in the dataset, not just the two most recent ones. 52.5 marks is simply ȳ, the average of all four marks scored, which ignores the study-hours input entirely. Regression predicts a value based on x; using the historical average of y regardless of x defeats the purpose of fitting a line in the first place. 81.25 marks comes from assuming marks are directly proportional to hours studied — scaling the (8, 65) point up as (10/8)×65 = 81.25 — which wrongly forces the line through the origin (a = 0) instead of using the fitted intercept of 30. Real least-squares lines from noisy data almost never pass exactly through (0, 0).

ExplanationComputing area = length × breadth for each row gives A: 10×60=600, B: 20×30=600, C: 30×40=1200, D: 15×20=300 sq. m. Dividing price by area: 30/600 = 0.05, 30/600 = 0.05, 60/1200 = 0.05, 15/300 = 0.05 lakh per sq. m — exactly ₹5,000/sq. m every single time, with zero error. So price = 0.05 × area holds perfectly across all four plots, meaning a model trained on `area` alone can fit this data with a perfect straight line and no residual error. Now check the raw features. Sorting by length: A(10 m, ₹30L) → D(15 m, ₹15L) → B(20 m, ₹30L) → C(30 m, ₹60L). As length rises from 10 to 15 m, price falls from 30 to 15 lakh; then from 15 to 20 m it rises back to 30 lakh; then to 60 lakh at 30 m. That fall-then-rise pattern means no single linear rule (or even a monotonic one) connects length to price — the same is true of breadth, which runs 60, 30, 40, 20 across A, B, C, D and shows no consistent trend with price either (e.g., breadth drops from 40 to 20 between C and D while price also drops, but breadth rises from 20 to 60 between D and A while price only rises to 30, not proportionally). This is the core lesson of feature engineering: the *information* needed to predict price (physical area) is already implicit in the two raw columns, but a simple model can't reconstruct a multiplicative relationship like length × breadth on its own from two separate linear inputs. Engineering the product explicitly hands the model the exact quantity it needs, turning a messy, non-monotonic two-feature problem into a perfect one-feature linear fit. Claiming area "cannot be used" because areas differ across plots misreads the table — A and B in fact share the same area (600 sq. m) and, correspondingly, the same price (₹30 lakh), which is itself evidence that area, not length or breadth, is the quantity driving price.

ExplanationPrecision answers a specific question: "Of everything the model called positive (fraud), how much actually was?" It is defined as TP / (TP + FP), using only the flagged transactions — not the whole dataset and not the actual fraud count. From the matrix, TP = 30 and FP = 150, so the model raised TP + FP = 180 total fraud alerts. Precision = 30 / 180 = 0.1667, which rounds to 17%. In plain terms: for every 6 alerts the fraud-review team receives, only about 1 is real fraud — the other 5 are legitimate UPI transactions wrongly flagged, which matters a lot for a team that has limited hours to manually review each alert. The 60% figure is Recall (TP / (TP+FN) = 30/50), a different question entirely — "of all the real fraud that happened, how much did the model catch?" A model can have decent recall while still burying its review team in false alarms, which is exactly this case. The 98% figure is overall Accuracy ((TP+TN)/10000 = 9830/10000), inflated by the 9800 correctly-ignored legitimate transactions. With fraud being rare (only 50 out of 10,000 cases), a model can score high accuracy while being nearly useless at its actual job of producing trustworthy fraud alerts — a classic accuracy-paradox trap with imbalanced data. The 83% figure comes from computing FP / (TP+FP) = 150/180 instead of TP / (TP+FP) — swapping the numerator. That ratio is the false-alarm rate among alerts, the complement of precision, not precision itself; reading it as "mostly trustworthy" inverts what the number actually says.