Grade 8 AI & Computer Science Practice Questions — Set 9

ExplanationBoth applicants earn an identical ₹50,000 a month, so each gets exactly the same income component: 0.4 × 50 = 20 points, added to the base 30 points, giving 50 points each before any zone bonus. The only thing that can pull their scores apart is the zone bonus. Applicant P, in a Zone A pin code, adds +25 to reach 30 + 20 + 25 = 75, which clears the 65-point threshold and is approved. Applicant Q, in a Zone B pin code, adds only +5 to reach 30 + 20 + 5 = 55, which falls short of 65 and is rejected. Because Zone A and Zone B pin codes are historically segregated along community lines in this city, the zone bonus effectively carries the same information as caste or community, even though no field in the formula is labeled "caste" or "community." This is called proxy discrimination: an algorithm can produce outcomes that are strongly correlated with a protected characteristic purely by relying on a variable, like a pin code, that is statistically entangled with that characteristic. It is why real fair-lending audits check disparate impact across pin codes, surnames, and school names, not just whether a protected field was literally typed into the model. The other claims fall for two classic traps. Insisting the algorithm is neutral simply because caste was never an input variable is the "fairness through unawareness" fallacy — removing a variable from the formula does not remove its influence if a correlated variable (the pin code) is still present. Defending the score gap as reflecting "genuinely" lower historical default rates in Zone A is circular: if those historical rates were themselves shaped by decades of the same segregation, using them to set today's zone bonus just launders old bias into a new decision instead of removing it. And because P and Q have identical income, the entire 20-point gap in their final scores comes entirely from the zone bonus, not from income — so treating income as the real decision-maker while the zone bonus is dismissed as having "no real effect" gets the arithmetic backwards.

ExplanationThe key fact is that `.*` is greedy: it always tries to consume as many characters as it can, and only gives characters back (backtracks) one at a time when the rest of the pattern fails to match. Trace it. The engine finds `txn="` at the very start of `log` and enters the group. Since `.*` doesn't match newlines but happily matches quote characters, it first grabs everything left in the string — all the way to the end. Then it tries to match the trailing literal `"` and fails, because there's nothing left. So it gives back one character at a time and retries. It only has to give back a single character, because the very last character of `log` is itself a `"` (the closing quote of `"FAILED"`). So the group ends up capturing everything between the first `txn="` and that final `"` — swallowing the entire middle of the string, including the second `txn="..."` and `status="..."` pairs along the way. That capture is: `UPI/408912345678" status="SUCCESS" txn="UPI/408998765432" status="FAILED` Since `re.findall` with a single group returns just the captured text (not the whole match), `result` is a one-element list containing exactly that string. After this single match consumes almost the entire log, only the trailing `"` is left unscanned — too short for a second `txn="..."` match, so no second element is ever found. The two-clean-values answer is what you'd get with a *non-greedy* quantifier, `r'txn="(.*?)"'` — the `?` after `*` makes the engine stop at the nearest `"` instead of the farthest one, which is almost always what you actually want when parsing repeated quoted fields. The "stops after one match" and "empty list" answers both misjudge how backtracking works: the pattern doesn't fail on embedded quotes (regex has no concept of "already used" quotes), and `findall` always keeps scanning for further matches in whatever text remains after each match — it's just that greedy backtracking here leaves almost nothing left to scan.

ExplanationWhen the axis starts at 80 instead of 0, a bar's visible height is proportional to (value - 80), not to the value itself. School A's bar rises 82 - 80 = 2 units above the axis start, and School B's bar rises 86 - 80 = 6 units. That makes the height ratio 6 : 2 = 3, so B's bar looks three times as tall as A's. But the real pass percentages differ by only 4 percentage points, giving an actual ratio of just 86/82 ≈ 1.05 - the schools' true performance is almost identical. By starting the y-axis at 80% instead of 0%, the chart stretches a tiny real gap into a visually huge one, which is exactly the kind of truncated-axis distortion (sometimes called an inflated "lie factor") that data journalists and CBSE data-handling lessons warn readers to check for: always look at where a bar chart's axis begins before trusting how big a difference looks.

ExplanationEvery relative path in HTML is resolved against the location of the file that contains it, not against the project's top-level folder. Because webdev.html lives inside projects/, one level below portfolio/, a single ../ is needed to step back out to the portfolio root before descending into css/ or images/ — so ../css/style.css and ../images/profile.jpg are the only paths that land on the real files. Writing css/style.css or ./css/style.css (both mean "look right here") tells the browser to search inside projects/css/style.css, a folder that doesn't exist, so the page loads unstyled and the image breaks — this is one of the most common bugs students hit the moment a portfolio grows past a single page. The path starting with a leading slash is an absolute path measured from whatever the browser treats as the domain root. That happens to work if a site sits at the very top of a domain, but a GitHub Pages project site is served from a URL like username.github.io/portfolio/, so /css/style.css actually points to username.github.io/css/style.css — a location that doesn't exist there either. It also fails when the file is opened straight from a computer, since file:// URLs have no shared root across folders. Only the double-dot path resolves correctly in every one of these situations.

ExplanationAt a 900px viewport, the browser evaluates every media query independently rather than picking a single "closest" breakpoint. The condition min-width: 480px is true (900 ≥ 480), min-width: 768px is true (900 ≥ 768), and min-width: 1024px is false (900 < 1024) — so three rules end up matching at once: the unconditional base rule, the 480px rule, and the 768px rule. All three declarations target the same body selector, so they have identical specificity, and the cascade falls back to source order: whichever matching rule appears last in the stylesheet wins. Since the 768px query's font-size: 18px comes after both the base rule and the 480px rule in the code, it overrides them, and 18px is what actually renders — not 16px, not 20px, and not the 14px fallback. This is exactly why mobile-first stylesheets are written with ascending min-width breakpoints: each new breakpoint's rule is meant to stack on top of and override every smaller breakpoint that also matches, not replace them outright. Confusing this with "only the nearest breakpoint applies" is a common bug source in real responsive layouts, where developers are surprised a style from a much smaller breakpoint is still technically "active" underneath the one they see rendered.

ExplanationTrace both formulas for request IDs 0 to 11. serverID = requestID mod 3: 0,1,2,0,1,2,0,1,2,0,1,2 serverID = requestID mod 4: 0,1,2,3,0,1,2,3,0,1,2,3 Comparing position by position: IDs 0, 1, and 2 happen to land on the same server under both rules (0→0, 1→1, 2→2), but every ID from 3 through 11 lands on a different server than before. That's 3 unchanged and 9 changed out of 12 — a 75% disruption rate from adding just one extra server. This matters because plain modulo routing ties every request's server assignment to the total server count. Change that count even slightly — scaling up during a Tatkal rush, or losing a server to a crash — and almost the entire mapping shifts, not just the requests handled by the new server. In a real system this would mean thousands of users mid-session (say, mid-payment on a booking) get silently routed to a server that has no record of their session, causing failed transactions right when traffic is heaviest. This exact weakness is why production load balancers use consistent hashing instead: it's designed so that adding or removing one server only remaps the small share of keys that specifically belong to that server, leaving the rest of the mapping untouched.

ExplanationWhen a message can arrive at the server at any random moment during the 4-second gap between two polls, its wait time before being picked up ranges from almost 0 seconds (it arrives just before a poll fires) up to almost the full 4 seconds (it arrives just after a poll fires). Averaged uniformly across all these equally likely arrival moments, the expected wait is exactly half the polling interval: 4 ÷ 2 = 2 seconds. This "average half-interval delay" is a fundamental cost of polling, independent of how fast the server itself responds — it is precisely why production chat systems like WhatsApp and Instagram DMs use WebSockets instead: a WebSocket keeps one connection open so the server can push a message the instant it exists, replacing this unavoidable 2-second average wait with just the raw network latency, typically well under 100 milliseconds.

ExplanationThe message triggers four of the five red-flag rules. The publisher is not on the verified list (-30). It uses ALL CAPS and multiple exclamation marks (-20). It has been contradicted by three independent fact-checkers, which satisfies the "2 or more fact-checkers" condition (-25). And its source domain is 2 months old, under the 6-month cutoff (-10). Those four penalties total 30 + 20 + 25 + 10 = 85, so the score drops from 100 to 15. The fifth rule, the forward-chain penalty, does not apply: the message was forwarded only 3 times, and the rule requires 5 or more hops before it fires. Treating any forwarding as enough to trigger that rule (subtracting the extra 15 anyway) is a common misreading of "IF forwarded through >= 5 hops" and produces an incorrect score of 0. Skipping the fact-checker-contradiction penalty entirely — for example, assuming only an official government retraction counts, not independent fact-checkers — gives 40, undercounting a genuine warning sign. Skipping both that penalty and the unverified-publisher penalty gives 70, which not only misstates the score but also flips the label from "Likely Misinformation" to the milder "Verify Before Sharing," even though two of the strongest evidence-based red flags (an unlisted publisher and direct contradiction by fact-checkers) are present. Since 15 is below the 60-point cutoff, "Likely Misinformation" is the correct label, and the key critical-thinking lesson is that sensational language and a young domain are weaker signals on their own than being contradicted by named fact-checking organisations and lacking any verifiable publisher.

ExplanationThe quantifier `+` in `.+` is greedy by default, which means the engine does not stop at the first opportunity to satisfy the rest of the pattern — it first tries to consume as many characters as possible (everything up to the end of the string), and only then backtracks, one character at a time, until whatever comes next in the pattern (here, the literal `>`) can finally match. Trace it: `re.search` anchors the attempt at the first `<` (index 0). `.+` grabs the rest of the string greedily: `b>Bold</b> and <i>Italic</i`. The pattern still needs a trailing `>`, so the engine backtracks from the end — but the very last character of `s` already is `>` (the close of `</i>`), so it only has to give back that one character before the match succeeds. It never needs to backtrack further, so it never gets a chance to stop at the `>` right after `<b`. The net effect: `.+` swallows straight through `Bold</b> and <i>Italic</i`, and `match.group()` returns the whole string, `<b>Bold</b> and <i>Italic</i>` — not just the first tag. This is exactly why greedy quantifiers are dangerous around repeated delimiters like HTML tags: to make the match stop at the nearest `>` instead, you would need the lazy version `.+?`, which tries to match as little as possible before checking whether the rest of the pattern can succeed.

ExplanationTrace it exactly as the algorithm would run. Array: index 0=15, 1=42, 2=8, 3=23, 4=91, 5=4, 6=67. Target = 8. Step 1: low=0, high=6, mid=(0+6)//2=3, arr[3]=23. Since 8<23, the algorithm assumes the target — if present — must lie strictly to the left, so it sets high=mid-1=2. Range is now indices 0–2, which still includes index 2 (value 8), so nothing has gone wrong yet. Step 2: low=0, high=2, mid=(0+2)//2=1, arr[1]=42. Since 8<42, high becomes mid-1=0. This is the fatal step: the new range is just index 0, so index 2 — where 8 actually lives — gets thrown away. Binary search "trusts" that anything below index 1 with a smaller value than 42 can't come after position 1, which is only a valid rule when the array is genuinely sorted ascending. Here it isn't: 8 sits at index 2, right after 42 at index 1, breaking that assumption. Step 3: low=0, high=0, mid=0, arr[0]=15. Since 8<15, high becomes -1. Now low(0) > high(-1), so the loop ends and the algorithm reports "not found". So the search compared against 23, then 42, then 15 — in exactly that order — and concluded 8 isn't present, despite it sitting at index 2 the entire time. This is the real danger of running binary search on unsorted data: it doesn't just get slower (like the infinite-loop misconception suggests, which is false — low and high do cross and the loop terminates cleanly), and it doesn't find the value at a wrong index either. It can silently return a false negative on data that's actually present, because every halving step depends entirely on the sorted-order guarantee. This is exactly why real systems (like a database index or an IRCTC seat-availability lookup) must guarantee sortedness before ever applying binary search — an unsorted binary search isn't a slower correct algorithm, it's a fast incorrect one.

ExplanationEvery cable in the mesh network is an edge, and each edge touches exactly two routers, adding 1 to the degree count of each of those two routers. This means the sum of the degrees of all vertices in any network always equals twice the number of edges — this is the Handshake Lemma, a core fact about graphs. With 9 direct connections in this network, the total degree sum must be 2 x 9 = 18. Adding up the five known degrees gives 3 + 4 + 2 + 5 + 3 = 17. So the sixth router's degree is 18 - 17 = 1: it has exactly one direct cable connection into the rest of the mesh. Getting 2 usually comes from mis-adding the five known degrees as 16 instead of 17. Getting 9 comes from confusing the total number of edges with the missing vertex's own degree, skipping the doubling step entirely. Getting 3 comes from assuming the missing router should just match the most common degree in the list rather than actually working out the total from the edge count.

ExplanationDelhi appears in three rows of the DataFrame, with sales values 200, a missing entry, and 100. pandas' groupby().mean() runs with skipna=True by default, so it does not zero-fill or crash on the missing entry — it simply excludes that row from both the sum and the count for the group. That leaves two valid numbers for Delhi, 200 and 100, which sum to 300; dividing by 2 (the count of valid entries, not 3) gives 150.0, exactly what result['Delhi'] prints. The 100.0 trap comes from wrongly treating the gap as a zero and dividing by all three rows (200 + 0 + 100 = 300, divided by 3); NaN would only be the output if skipna were explicitly turned off with mean(skipna=False); and 200.0 confuses an aggregation like mean() with simply grabbing the first value stored in the group.

ExplanationBeautifulSoup does not store a tag's class attribute as one single string — it splits it on whitespace into a list of separate class tokens, and class_='available' matches a tag if 'available' appears anywhere in that list, regardless of position or of what other classes sit alongside it. Checking all four div tags: class="available" has the token list ["available"], which contains "available", so it matches. class="train-card available" has tokens ["train-card", "available"] — "available" is present even though it isn't the first token, so it matches too. class="available premium" has tokens ["available", "premium"], which also contains "available", so it matches. class="availableSoon" has just one token, "availableSoon", and that token is not equal to "available" — BeautifulSoup compares whole tokens, not substrings or prefixes, so this div is excluded. That gives 3 matching div tags in total. The idea that a substring or prefix match happens is a common mix-up with how CSS attribute selectors like [class^="available"] work, but plain class_ matching in BeautifulSoup never does partial-word matching — 'availableSoon' and 'available' are simply different tokens. Requiring the class attribute to be exactly the single word 'available' is also incorrect, since BeautifulSoup treats a multi-valued class attribute as a list and checks membership in that list rather than comparing it as one combined string, so extra classes on the same tag don't disqualify a match. Finally, position inside the class attribute is irrelevant — BeautifulSoup checks whether 'available' is present anywhere in the token list, not only when it happens to be listed first.

ExplanationThe loop condition `range(len(marks) - 1)` is the bug. For the 5-element list, `len(marks) - 1` is 4, so `range(4)` only produces the indices 0, 1, 2, 3 — the loop body never runs for `i = 4`, and `marks[4]` (the mark 95) is silently skipped. So `total` only accumulates `marks[0] + marks[1] + marks[2] + marks[3] = 72 + 85 + 90 + 68 = 315`. The return line then divides by `len(marks)`, which is still the true length, 5 (this part of the code was never shortened) — giving `315 / 5 = 63.0`. That rules out 78.75, which is what you'd get only if the denominator had also been reduced to 4 (`315 / 4`), and it rules out 102.5, which comes from mixing the full correct sum of 410 with the shortened denominator of 4 (`410 / 4`). It also rules out 82.0, the true average (`410 / 5`) a reader gets only by assuming the function has no bug at all. Because the `assert` statement compares the real return value, 63.0, against the expected 82.0, the assertion fails — and that failure is exactly what points a tester to the classic off-by-one mistake: `range(len(marks) - 1)` should have been `range(len(marks))` so every mark, including the last one, gets added in.

ExplanationCreating an object in Python is a two-step process: `__new__` builds (or fetches) the object, and then Python automatically calls `__init__` on whatever `__new__` returned — as long as that return value is an instance of the class. This second step is the part beginners miss when they write a Singleton this way. Trace it carefully. When `c1 = Counter()` runs, `cls._instance` is `None`, so `__new__` creates a fresh object and stores it in `cls._instance`. Because that returned object is a `Counter` instance, Python then calls `__init__` on it, setting `self.count = 0`. The line `c1.count = 5` changes that same object's `count` to 5. Now `c2 = Counter()` runs. Inside `__new__`, `cls._instance` is no longer `None`, so the `if` block is skipped and the *existing* object is returned — this part of the Singleton logic works correctly, and `c2` is genuinely the same object as `c1` (`c1 is c2` would be `True`). But `__init__` does not know or care that this object already existed. Python calls `__init__` again simply because `__new__` handed back a `Counter` instance, so `self.count = 0` runs a second time, overwriting the 5 with 0 on that shared object. So `print(c2.count)` outputs 0 — but not because `c2` is a separate, unrelated object (it isn't), and not because Python skips re-initialization for existing instances (it doesn't skip it at all). A correct Singleton implementation must guard `__init__` itself, for example with `if not hasattr(self, "count"): self.count = 0`, otherwise every "new" call quietly resets state — a bug that defeats the whole purpose of the pattern.

ExplanationThe line `g = gen()` only creates a generator object — none of the code inside `gen` runs yet, because a function containing `yield` doesn't execute when called, it just returns a paused iterator. So `print("start")` fires first, with no "A" before it. The first `next(g)` call is what actually starts running the function body: it executes `print("A")`, then hits `yield 1`, which freezes execution right there and hands back 1 as `x`. That's why "got 1" follows "A". Crucially, the generator does not restart from the top on the next call — it resumes exactly where it froze. So the second `next(g)` continues immediately after `yield 1`, runs `print("B")`, then hits `yield 2` and freezes again, giving `y = 2` and printing "got 2". Putting it together: `start`, `A`, `got 1`, `B`, `got 2` — five lines, each print statement firing only when execution actually reaches it, never before the generator is asked to advance and never repeated. `print("C")` never runs at all, since a third `next(g)` was never called. The other sequences reflect two classic misconceptions: assuming the generator body runs eagerly the moment `gen()` is called (producing "A", "B", "C" before "start" even prints), and assuming each `next()` call restarts the function from its first line instead of resuming from the last `yield` (which would reprint "A" on the second call).

ExplanationStacked decorators apply from the function outward, not from top to bottom in reading order. The decorator written directly above the function — add_one — wraps the original square first, so square becomes equivalent to add_one(original_square). Only after that does double wrap the already-wrapped version, so square finally becomes double(add_one(original_square)). Calling square(3) therefore runs double's wrapper, which calls add_one's wrapper, which calls the original square: original_square(3) gives 3 × 3 = 9, add_one's wrapper adds 1 to get 9 + 1 = 10, and double's wrapper doubles that to 2 × 10 = 20. Reading the decorators in the wrong order — treating double as if it ran first — is the classic trap, and it produces 2 × 9 + 1 = 19 instead. Assuming one decorator simply overwrites the other, rather than each wrapping the previous result, gives the remaining incorrect values of 18 or 10.

ExplanationTrace the insertions one at a time, computing h(k) = k mod 7 and probing forward whenever a bucket is already taken. - 23 mod 7 = 2 (since 7×3 = 21, remainder 2) → bucket 2 is empty → 23 goes to index 2. - 15 mod 7 = 1 (7×2 = 14, remainder 1) → bucket 1 is empty → 15 goes to index 1. - 9 mod 7 = 2 → bucket 2 already holds 23 (collision) → probe index 3, which is empty → 9 goes to index 3. - 40 mod 7 = 5 (7×5 = 35, remainder 5) → bucket 5 is empty → 40 goes to index 5. - 16 mod 7 = 2 → bucket 2 holds 23 (collision) → probe index 3, which holds 9 (second collision) → probe index 4, which is empty → 16 goes to index 4. So the final table is: index 1 → 15, index 2 → 23, index 3 → 9, index 4 → 16, index 5 → 40, with indices 0 and 6 empty. Key 16 needed two probes past its natural home bucket before finding a free slot, landing at index 4. Index 2 is only where 16's hash function *starts* looking — it's the home bucket for 23, not 16's final resting place, so stopping there ignores the two collisions that follow. Index 3 is where the previous key, 9, ended up after its own single collision — mixing up 9's final index with 16's is an easy slip since both keys collide with 23 in the same bucket. Index 5 overshoots by one step, as if 16 had to probe past 40's bucket too, but 40 sits at index 5 (its own natural hash) and was never in 16's probing path — 16's probe sequence only touches indices 2, 3, and 4 before finding the empty slot.

ExplanationThe bug is a classic boundary-value (off-by-one) error: the spec says "₹1000 or more" (price >= 1000), but the code tests `price > 1000`, a strictly-greater comparison that silently excludes the exact value ₹1000. Tracing `calculateDiscount(1000, false)`: `1000 > 1000` is false, so `discount` stays 0, and since `isMember` is false nothing is added. The function returns `1000 - (1000 * 0) = ₹1000`. The test asserts the result should be ₹900 (10% off a ₹1000 order), so the assertion fails — the code and the spec disagree exactly at the boundary. The other three tests all pass, but not because the code is correct — it's because none of them sits on the boundary, so the `>` vs `>=` bug never gets triggered: - `calculateDiscount(1500, false)`: `1500 > 1000` is true, discount = 0.10, result = `1500 - 150 = ₹1350`, matching the expected ₹1350. - `calculateDiscount(500, true)`: `500 > 1000` is false (discount 0), `isMember` adds 0.05, result = `500 - 25 = ₹475`, matching the expected ₹475. - `calculateDiscount(2000, true)`: `2000 > 1000` is true (discount 0.10), plus member's 0.05 = 0.15, result = `2000 - 300 = ₹1700`, matching the expected ₹1700. This is exactly why unit testing relies on boundary value analysis: picking test inputs safely above or below a threshold can make a suite look green even though a single off-by-one mistake breaks behavior right at the edge. A thorough test suite must always include the exact threshold value itself, not just values comfortably on either side of it.

ExplanationRobots.txt matching works on longest-prefix-wins, not on which line appears first in the file. Check /products/sale/summer-collection against each rule: it starts with "/products/" (10 characters, a Disallow) and it also starts with "/products/sale/" (15 characters, an Allow) — but it does not start with "/products/sale/limited/" (23 characters), since the text after /products/sale/ is "summer-collection", not "limited/". Between the two rules that do match, 15 characters beats 10, so the Allow rule wins and this path can be crawled. The other three paths all end up blocked. /products/electronics/mobiles never reaches the word "sale" at all, so the only rule it matches is the 10-character Disallow: /products/ — blocked. /products/sale/limited/diwali-offer matches all three rules (10, 15, and 23 characters), but the longest match is the 23-character Disallow: /products/sale/limited/, which overrides the shorter Allow rule — blocked. /products/sale itself is only 14 characters long with no trailing slash, so it cannot start with the 15-character string "/products/sale/" (a path can't match a prefix that is longer than the path itself); it only matches the 10-character Disallow: /products/ rule, so it's blocked too.