Grade 8 AI & Computer Science Practice Questions — Set 10

ExplanationThe browser lays out a grid in a fixed order: first it hands out space to fixed-size tracks, then to gaps, and only what's left over gets divided among the flexible `fr` tracks in proportion to their fr values. Here the container is 580px wide with three columns, so there are two gaps between them: 2 × 20px = 40px reserved for gaps. The fixed track takes 60px. That leaves 580 − 60 − 40 = 480px to be shared between the `1fr` and `3fr` tracks. Those two tracks together represent 1 + 3 = 4 fr "shares," so each share is worth 480 ÷ 4 = 120px. The `1fr` column therefore renders at 1 × 120px = 120px (and the `3fr` gallery column takes the remaining 3 × 120px = 360px). Adding everything back up confirms it: 60px + 120px + 360px + 40px of gaps = 580px, exactly matching the container. 130px comes from forgetting to remove the gap space before dividing (580 − 60 = 520, then 520 ÷ 4 = 130). 135px comes from the opposite slip — forgetting to remove the fixed 60px track (580 − 40 = 540, then 540 ÷ 4 = 135). 160px comes from dividing the correct 480px leftover by the number of columns (3) instead of the number of fr shares (4). Each of these skips one step of the two-stage allocation that `fr` units actually use: fixed and gap space is committed first, and only the remainder is split proportionally among the fr tracks.

ExplanationIn row-major order, the computer lays every row of the array end-to-end in memory before starting the next row, so reaching marks[12][3] means first skipping 12 complete rows of 5 marks each, then 3 more marks within row 12: (12 × 5) + 3 = 63 marks come before it. Since each mark is a 4-byte integer, those 63 skipped marks occupy 63 × 4 = 252 bytes. Adding that offset to the base address gives 2000 + 252 = 2252, the correct memory address. 2063 comes from computing the right element count (63) but forgetting that each element takes 4 bytes of memory — adding the raw count of skipped elements directly to the base address instead of converting it to bytes first. 2272 comes from an off-by-one indexing slip: treating "the 13th student" as row index 13 instead of remembering that 0-based indexing makes the 13th student row 12. Using row 13 gives (13 × 5 + 3) × 4 = 272, and 2000 + 272 = 2272. 2528 comes from mixing up row-major and column-major layout — computing the offset as if columns were stored first, using (column × number of rows + row) instead of (row × number of columns + column): (3 × 40 + 12) × 4 = 528, giving 2000 + 528 = 2528. This is the address the element would have under column-major storage, not the row-major layout the array actually uses.

ExplanationPygame's colliderect() checks real overlap, not mere contact: for two rects it requires enemy.x < player.x + player.width AND player.x < enemy.x + enemy.width (plus the matching pair on the y-axis) — all with strict inequalities, so edges that only touch do not count as colliding. Here the player's y-range (200 to 250) already overlaps the enemy's y-range (180 to 220) on every single frame, so the outcome is decided entirely by x. The player starts at x = 100 and gains 5 pixels each frame, so after k frames its position is x = 100 + 5k. The overlap requirement 250 < x + 50 simplifies to x > 200, and since x only ever lands on multiples of 5 above 100, the first value that actually clears 200 is x = 205 — not x = 200, which merely touches the enemy's edge and still fails the strict inequality. Reaching x = 205 takes k = 21 frames (100 + 5 x 21 = 205). At 60 FPS, 21 frames correspond to 21 / 60 = 0.35 seconds, which is exactly what print(frame / fps) outputs. A student who accepts x = 200 as "touching = colliding" stops one frame early and gets 0.33 seconds, while a student who forgets to add the player's own 50-pixel width before comparing to the enemy's edge waits until x = 250, overshooting to 0.50 seconds — both errors come from misreading how colliderect()'s strict overlap test actually works.

ExplanationSince die1 and die2 are two separate calls to the generator, treat every ordered pair (die1, die2) as a distinct, equally likely outcome — there are 6 x 6 = 36 such pairs in total, and (5,3) is a different outcome from (3,5) even though both sum to 8. The condition "at least one call returned 5" shrinks the sample space before you even look at the sum. List every pair containing a 5: with die1 = 5, die2 can be 1, 2, 3, 4, 5, or 6 (6 pairs); with die2 = 5, die1 can be 1, 2, 3, 4, or 6 (5 more pairs, since (5,5) was already counted). That's 11 equally likely outcomes forming the new, restricted sample space. Now check which of those 11 pairs sum to 8: only (5,3) and (3,5) qualify — (5,5) sums to 10, (5,1) to 6, (5,2) to 7, (5,4) to 9, (5,6) to 11, and their mirror images give the same sums. So 2 of the 11 restricted outcomes are favorable, giving a conditional probability of 2/11. 5/36 is the *unconditional* probability of rolling a sum of 8 (5 favorable pairs out of the original 36) — it ignores that the sample space was already narrowed down by the "at least one 5" condition, so the denominator is wrong. 1/6 comes from a subtly different question: if you already knew one *specific* die (say die1) was fixed at 5, the other die would need to show 3, giving 1/6 — but "at least one die shows 5" doesn't tell you which die it is, so this undercounts the true restricted sample space (11 outcomes, not 6). 1/11 comes from correctly finding the 11-outcome restricted sample space but then treating (5,3) and (3,5) as the same outcome and counting only 1 favorable case, which double-loses information since the two random_int() calls are independent and order matters.

ExplanationConverting each operand to decimal first: 11011010 = 128+64+16+8+2 = 218, and 10110111 = 128+32+16+4+2+1 = 183. Their true sum is 218+183 = 401, which needs 9 bits (110010001 in binary) because it exceeds 255, the largest value an 8-bit register can hold. Since the register is only 8 bits wide, the carry out of bit 7 is not stored anywhere — it simply vanishes, exactly the way real fixed-width hardware registers overflow. What remains is 401 mod 256 = 145, i.e. the low 8 bits 10010001. Splitting 10010001 into two nibbles, 1001 and 0001, gives the hex digits 9 and 1, so the register's final content is 0x91. Discarding the carry from the top of the number, the way overflow always works, is different from lopping a digit off the bottom, and it is also not the same operation as an XOR, which throws away every carry generated during the addition rather than just the one carry that overflows the register's width.

ExplanationThe function scores each intent as (matched keywords) ÷ (total keywords defined for that intent) — a normalized confidence, not a raw match count. For the message "hi can you tell me the weather forecast for tomorrow", the unique word set is {hi, can, you, tell, me, the, weather, forecast, for, tomorrow}. greeting's keyword set is {"hello", "hi"} (2 keywords); only "hi" matches, so confidence = 1/2 = 0.5. weather's keyword set is {"weather", "rain", "temperature", "forecast", "climate"} (5 keywords); two words match ("weather" and "forecast"), so confidence = 2/5 = 0.4. book_ticket's keywords {"book", "ticket", "train", "irctc", "pnr"} never appear in the message at all, so its confidence is 0 — the word "tomorrow" is not one of its keywords and the code has no logic that treats travel-sounding words as booking signals. Walking through the loop in insertion order: greeting sets best_confidence to 0.5, then weather's 0.4 fails to beat it, then book_ticket's 0 also fails, so best_intent stays "greeting". Since 0.5 is not less than the 0.3 threshold, the "sorry" fallback never fires, and the function returns "greeting". This is a genuine trap in keyword-based chatbot design: an intent with fewer, more specific keywords can outrank an intent with more raw matches once the score is normalized by keyword-set size — which is exactly why real systems, including an IRCTC-style ticket-booking bot, use a normalized confidence rather than a plain match count to decide which intent to trust.

ExplanationThe value after "Basic" in an HTTP Basic Authentication header is not encrypted or hashed — it is Base64, a reversible text encoding with no secret key. Decoding YWRtaW46UGFzc3cwcmQh gives back exactly admin:Passw0rd!, the original username:password pair, using nothing more than a public, standard decoding table that any programming language can run in one line of code. That is precisely why HTTP Basic Authentication must always travel over HTTPS/TLS: TLS encrypts the entire request, including this header, so an eavesdropper only ever sees ciphertext. Sent over plain HTTP as in this scenario, the credentials are exposed the instant the request is captured — reversing Base64 takes no computing power and no key at all. It also is not a cryptographic hash, since hashes are one-way by design and cannot be decoded back into their original input the way Base64 can. And it has nothing to do with OAuth 2.0's delegated-trust model, where a separate authorization server verifies identity once and issues a short-lived access token, rather than the client resending raw, reversible credentials on every single request.

ExplanationGrouping the six rows by city produces three buckets: Delhi has three rows with delays 15, 30, and 0, giving count 3 and average 45/3 = 15.0; Mumbai has two rows with delays 0 and 10, giving count 2 and average 10/2 = 5.0; Chennai has a single row with delay 5, giving count 1 and average 5.0. HAVING runs after grouping, not before, so HAVING COUNT(*) >= 2 checks each group's row count and drops Chennai's single-row group while keeping Delhi and Mumbai. The SELECT clause lists city, COUNT(*), then AVG(delay) in that order, so each surviving row is a tuple with city first, the integer count second, and the float average third — never swapped. ORDER BY AVG(delay) DESC then sorts the surviving groups by their average delay from highest to lowest, not alphabetically by city: Delhi's average of 15.0 is higher than Mumbai's 5.0, so Delhi's tuple is listed first. Since sqlite3's fetchall() returns query results as a list of tuples, the final result is [('Delhi', 3, 15.0), ('Mumbai', 2, 5.0)].

ExplanationThe trace is the key debugging clue here: it prints exactly 4 "added marks[...]" lines, for indices 1 through 4, and index 0 never appears. That pins the bug precisely to `range(1, len(marks))` — it should be `range(len(marks))` (equivalently `range(0, len(marks))`) so the loop starts at index 0 and includes `marks[0]`, which is 78. Adding up all five scores correctly gives 78 + 85 + 92 + 66 + 90 = 411, and dividing by the full count of 5 scores gives 411 / 5 = 82.2 — the true average. The buggy version only summed 85 + 92 + 66 + 90 = 333 and divided by 5, giving the incorrect 66.6 shown in the trace. This illustrates why tracing intermediate values (not just the final output) is such a powerful debugging technique: the missing "marks[0]" line in the output immediately localizes the bug to the loop's starting bound, rather than leaving you guessing between the loop, the sum, or the division. The other explanations don't survive a check against the code or the trace: `total = 0` is already present before the loop, so it isn't left over from a previous call; patching the divisor to `len(marks) - 1` treats a loop bug as if it were a division bug, and only coincidentally lands near the right ballpark (333/4 = 83.25, still wrong); and a `print()` statement never modifies a program's variables — it only displays them, so removing it cannot change what `total` evaluates to.

ExplanationVelocity in Scrum is the amount of work (in story points) a team completes per sprint, and it's forecast using an average over several recent sprints, not a single sprint's number. Here the average velocity is (20 + 25 + 18) ÷ 3 = 63 ÷ 3 = 21 story points per sprint. To clear a 130-point backlog at that rate: 130 ÷ 21 ≈ 6.19 sprints. A team can't ship "0.19 of a sprint" — after 6 full sprints they'd have completed 6 × 21 = 126 points, leaving 4 points still undone, which forces a 7th sprint to finish. This rounding-up step is exactly why sprint forecasts in real Agile teams (and in exam questions about them) almost always come out as a ceiling, not a plain division answer. The tempting wrong turns are: stopping at the raw division result of 6 without accounting for the leftover 4 points; anchoring on just the latest sprint's velocity (18) instead of smoothing across sprints, which understates how much the team typically delivers and inflates the forecast to 8; and confusing "total points delivered so far" (63) with "points delivered per sprint," which would wrongly suggest the backlog clears in just 3 sprints.

ExplanationView Source (Ctrl+U) requests the raw HTML document exactly as the server sent it, before any JavaScript ran — so it will always show "Checking availability...", the placeholder baked into that original file, no matter what happens on the page afterward. The Elements panel, by contrast, is not displaying a saved file at all; it renders the browser's current, in-memory DOM tree, which is kept continuously in sync with whatever JavaScript changes on the page. Since the fetch call already rewrote that node's text to "12 seats available" before the student opened DevTools, that is exactly what the Elements panel shows. This gap between "what the server originally sent" and "what is actually on screen right now" is precisely why View Source is unreliable for inspecting dynamic, JavaScript-driven pages, while the Elements panel is the tool built for that job — it updates live as scripts modify the DOM, it doesn't need a manual page reload to catch up, and Ctrl+U never re-fetches anything after scripts run.

ExplanationThe duty-cycle formula applies to the whole parenthesized expression: duty = 4 × (32 − 20) = 4 × 12 = 48, which already sits inside the 0–100 clamp, so `ChangeDutyCycle(48)` runs unchanged. A 100 Hz PWM signal repeats every 1 / 100 Hz = 10 ms, and a 48% duty cycle means GPIO18 is driven HIGH for 48% of that period: 0.48 × 10 ms = 4.8 ms, then LOW for the remaining 5.2 ms. The 48 ms distractor comes from confusing frequency with period (treating 100 Hz as if it meant a 100 ms cycle instead of taking its reciprocal). The 10 ms distractor comes from breaking operator precedence — computing 4 × 32 − 20 = 108 instead of 4 × (32 − 20) — which clamps to 100% and forces the pin fully HIGH. The 5.2 ms distractor swaps the ON and OFF portions of the cycle, reporting how long the pin is LOW rather than HIGH.

ExplanationThink of the printed cube as two separate regions: the solid outer shell, and the hollow interior that's only partly filled. Outer cube volume = 50 × 50 × 50 = 125,000 mm³. Because the shell is 5 mm thick on every face, it eats into the cube from both opposite sides along each dimension — so the inner hollow cube's side length is 50 − (5 + 5) = 40 mm, giving an inner volume of 40³ = 64,000 mm³. The shell itself is 100% solid plastic: 125,000 − 64,000 = 61,000 mm³. Of the 64,000 mm³ inner cavity, only 20% gets filled by the lattice: 0.20 × 64,000 = 12,800 mm³. Total printed plastic = 61,000 + 12,800 = 73,800 mm³. As a share of the whole cube: 73,800 ÷ 125,000 = 0.5904 = 59.04%. The concept a slicer actually uses: the infill percentage applies only to the hollow interior left over after the solid perimeter walls are printed — never to the entire part. Treating "20% infill" as "20% of the whole object" ignores the solid shell completely. Applying 20% to the full 125,000 mm³ instead of just the 64,000 mm³ cavity over-counts material, since it double-charges the wall region for infill it doesn't need. And subtracting the wall thickness from only one face (giving an inner side of 45 mm) instead of both opposing faces (giving 40 mm) undercounts how much of the cube the shell actually occupies.

ExplanationFollow the three chained array methods in the order they actually run on the five-project list. filter(p => p.featured) keeps only projects with featured: true, removing Chess AI (45 stars, not featured) and Snake Game (19 stars, not featured). That leaves Weather App (12 stars), Portfolio Site (8 stars), and Todo List (30 stars), still in their original array order. Next, sort((a, b) => b.stars - a.stars) reorders this filtered list from highest star count to lowest — the comparator returns a negative number whenever b has more stars than a, which pushes b earlier — giving Todo List (30), Weather App (12), Portfolio Site (8). Finally, slice(0, 2) keeps only the first two entries of that sorted list, dropping Portfolio Site, and .map(p => p.name) pulls out just the names. So console.log prints ["Todo List", "Weather App"]: the two featured projects with the highest star counts, higher-starred one first. Sorting all five projects by stars without filtering first would wrongly let the unfeatured Chess AI through; sorting ascending instead of descending would put the lowest-starred projects first; and skipping the sort entirely would just preserve the filtered list's original array order instead of ranking by popularity.

ExplanationIn the ping-pong style of pair programming, whose turn it is depends on who last made a test pass — not on a fixed rotation and not on whether the test number is odd or even. The rule is: pass a test, then immediately write the next failing test for your partner to solve. Tracing the sequence from the start makes this concrete. Aditi writes Test 1, which fails, and Rohan makes it pass — so by the rule, Rohan writes Test 2. Aditi then makes Test 2 pass, so Aditi writes Test 3. Rohan makes Test 3 pass, so Rohan writes Test 4. Notice that the writer of any test is always the person who passed the previous one, so the same partner naturally does two jobs back to back: Rohan passes Test 3 and then writes Test 4. This is what separates ping-pong pairing from plain driver/navigator pairing, where the two roles typically switch on a fixed timer (say, every 10 minutes) regardless of what just happened in the code — here, the switch is triggered entirely by who resolved the previous test.

ExplanationEvery Android build carries two separate version fields: versionName, the human-readable string like "1.1.1" shown on the store page, and versionCode, a plain integer the Play Console uses internally to decide upload order. The rule it enforces has nothing to do with semantic versioning — it only tracks the single highest versionCode ever accepted for that app, and every new upload's versionCode must be strictly greater than that running maximum. Tracing Priya's four uploads: after upload 1 the accepted maximum is 1, after upload 2 it is 2, and after upload 3 it is 4 (skipping 3 is perfectly legal — the rule is "strictly increasing," not "consecutive," so no gap check ever fires, which rules out treating upload 3 as the failure). When upload 4 arrives with versionCode 3, the console compares 3 against the current maximum of 4. Since 3 is not greater than 4, the upload is rejected — regardless of the fact that "1.1.1" reads as newer than "1.1.0" to a human. To get the hotfix accepted, Priya must rebuild it with versionCode 5 or higher; the versionName string can stay "1.1.1" or even go back to something that looks smaller, since Play Console never inspects it for ordering. There's also no such thing as a same-day or same-week upload limit, so nothing rejects upload 2 either.

ExplanationModel A is the better choice for deployment, because what matters is how a model performs on data it has never encountered — exactly what the 150-message test set measures. Model A's accuracy barely changes between training and test: 90% (180/200) versus 88% (132/150), a two-point gap. Model B's accuracy collapses from a perfect 100% (200/200) on training data to just 60% (90/150) on the test data, a forty-point gap. A model that scores perfectly on the data it was trained on but performs far worse on new data is exhibiting overfitting: instead of learning general features of spam (words like "WON", "click here", suspicious links), Model B essentially memorised the exact wording, senders, and quirks of the 200 training messages, none of which repeat in new messages. A 100% training score does not prove a model has learned the "true rule" — it can just as easily mean the model has memorised noise specific to that data, which is why trusting training accuracy alone, or trusting it because it came from a larger sample (200 vs. 150), is misleading; the size of the training set does not make an overfit score more reliable. Averaging training and test accuracy also hides the real story, since it treats memorisation and genuine generalisation as equally meaningful when they are not. Model A's small, stable gap between training and test performance is the real evidence that it has learned patterns that will keep working on spam messages it hasn't seen yet.

ExplanationGrover's algorithm achieves what's called a quadratic speedup: for N items, it needs on the order of √N steps instead of N. Here N = 1,000,000 IRCTC PNR records, so √1,000,000 = 1,000 — meaning about 1,000 amplitude-amplification steps are enough to find the target record with high probability, compared to up to 1,000,000 checks a classical computer might need if it inspects records one at a time in the worst case. That's roughly a 1,000-fold reduction in steps, not the exponential (log N ≈ 20) speedup that algorithms like Shor's factoring algorithm provide — Grover's search is famously powerful, but only quadratically so, and mixing it up with Shor's exponential speedup is a common mistake. The "no advantage" idea is also wrong: although measurement does collapse a superposition to a single outcome, Grover's algorithm uses interference to amplify the probability amplitude of the correct answer across those ~1,000 rounds before that final measurement, which is precisely how it beats classical search rather than gaining nothing from it. And the speedup doesn't come from a simple "one qubit doubles the speed" idea either — the √N scaling comes from how many amplitude-amplification rounds are needed to boost the right answer's probability close to 1, not from counting states two at a time.

ExplanationThe scenario describes data being collected for one clearly stated reason, personalized health statistics, and then reused for a completely different reason, advertising, and handed to outside companies, all without the app going back to ask permission again. This is precisely what purpose limitation protects against: once a user consents to their data being used for a specific, named purpose, that data cannot be repurposed for something unrelated, such as marketing, unless fresh and specific consent is obtained for the new use. The problem here is not the amount of data gathered, since location, step count, and heart rate are all reasonable inputs for a health-tracking feature, which rules out a data minimization issue. Nothing in the scenario involves the user trying to delete their account or stored information, so no erasure request has been denied, and nothing involves the user trying to move their data to a competing app, so no portability request has been ignored either. Under India's Digital Personal Data Protection Act, 2023, and privacy frameworks used worldwide, consent is always tied to the specific purpose it was given for, and any expansion of that purpose requires the data fiduciary to return to the user for permission.

ExplanationThe inner loop performs exactly i operations on every pass of the outer loop, and i doubles each time — 1, 2, 4, 8, and so on — until it passes n, which is why the outer loop itself runs only about log n times. Summing a doubling sequence like 1 + 2 + 4 + ... up to roughly n is a geometric series, and the defining property of such a series is that its total stays proportional to the largest term alone, which here is close to n. That means the total number of times `count += 1` executes across the whole function scales directly with n rather than with n multiplied by log n, so multiplying the outer loop's log n passes by the inner loop's largest possible size overcounts the work, since the inner loop stays far smaller than n for most of the run. Assuming the outer loop's small iteration count determines everything ignores how much work each of those iterations actually performs, and assuming any nested-loop structure must be quadratic ignores that the inner loop here only reaches a size close to n on its very last pass rather than on every pass.