Grade 9 AI & Computer Science Practice Questions — Set 4

ExplanationHTTP/2 solves the head-of-line blocking problem that plagues a single HTTP/1.1 connection by multiplexing several independent streams over one TCP connection. Each request and response is broken into small frames, and every frame carries a stream ID showing which exchange it belongs to, so frames from different streams can be interleaved on the wire and reassembled independently at each end. This means the slow image simply has no frames to send yet — frames belonging to the other 5 streams keep flowing normally, and those responses finish as soon as their data is ready, with no need to wait for the image. That is precisely why HTTP/2 needs only one connection where HTTP/1.1 often needed several: instead of dodging in-order delivery by opening parallel connections, HTTP/2 fixes the ordering problem inside a single connection through stream IDs and frame interleaving, so a slow response degrades only itself, not the whole connection.

ExplanationGraphQL executes resolvers field by field, not as one combined query plan. The authors resolver runs once and returns an array of 50 author objects. Because each field on each returned object is resolved independently unless the server explicitly batches the calls (for example with a DataLoader), the engine then invokes the Author.posts resolver separately for every one of those 50 authors. That is 1 query for the author list plus 50 queries for posts, totaling 51 database round-trips. GraphQL does not auto-join across resolvers or auto-batch same-type fields on its own — unmanaged nested resolvers fetching related data one parent at a time is exactly the N+1 problem that GraphQL servers need dedicated batching to avoid.

ExplanationWebRTC intentionally does not define how two browsers first find each other — that job is called "signaling," and the spec leaves it entirely to the application. Before pc.setLocalDescription(offer) and the later setRemoteDescription() on the other side complete, there is no peer-to-peer path at all, so the offer's SDP and each ICE candidate gathered by onicecandidate have nowhere to travel except an out-of-band channel the developer sets up — here, the WebSocket (ws). Once both sides have exchanged offer/answer and enough candidates, ICE connects the peers directly and further media/data flows through pc, not ws. The other options describe mechanisms WebRTC does not have: RTCPeerConnection has no "permission token" step gating direct sends, SDP has no such single-message size limit forcing frame-splitting, and ICE candidates are exchanged as plain JSON over whatever channel the app chooses — encryption is applied later, at the DTLS/SRTP layer once the connection is up, not by onicecandidate itself.

ExplanationA JWT has three parts: header.payload.signature. The signature is computed as HMAC-SHA256(base64url(header) + \".\" + base64url(payload), SECRET) — it is a cryptographic seal over the exact bytes of the header and payload, not an encryption of them. Editing the payload (even by one character, like changing \"user\" to \"admin\") changes those bytes, so when jwt.verify() recomputes the HMAC-SHA256 signature from the (now-altered) header and payload and compares it to the signature attached to the token, the two no longer match. Because the client doesn't know SECRET, it cannot produce a matching signature for its edited payload. jwt.verify() therefore throws (a JsonWebTokenError for invalid signature), the middleware's catch(e) block runs, and the server correctly responds with 403 {\"error\": \"Invalid token\"} — the tampered request never reaches next(). The key misconception this question targets: JWT payloads being merely base64-encoded (readable, not secret) is true, but that does NOT mean they're unverified — the signature is what enforces integrity, independent of the payload being human-readable.

ExplanationArray.prototype.filter has no early-exit condition — window.filter(t => now - t < this.windowMs) always walks the entire array from start to finish before it returns anything, so with 200 stored timestamps it inspects all 200 of them, producing a valid array of length 200 (since none have expired yet). Only after filter finishes does the code check valid.length >= this.limit; since 200 >= 5, allow() returns false. The limit parameter never influences how many elements filter visits during the scan — it is only compared against the result afterward. So the cost of an allow() call grows with however many timestamps are currently stored for that client, not with the configured limit, and not with the O(1) cost of Map.get()/Map.set() — those are constant-time only for locating the array itself, not for scanning everything inside it.

ExplanationWith new Pool(1), max is 1, so only one connection may exist. The first acquire() call finds this.free empty, but this.size (0) is less than this.max (1), so it increments size to 1 and awaits createConnection(), returning the pool's single connection. By the time the second acquire() runs, this.size (1) is no longer less than this.max (1), and this.free is still empty because nothing has been released, so both the free-array check and the size check fail and execution falls through to `return new Promise(resolve => this.waiting.push(resolve))` — the call's resolve function is stored in this.waiting and the promise stays unresolved. The third call behaves identically, so this.waiting ends up holding two resolve functions, each waiting for a future release(conn) call to hand it a connection through this.waiting.shift()(conn). No error is thrown, because the pool is built to queue callers rather than reject them once the limit is hit; no additional connection gets created beyond the first, because the size-versus-max guard blocks that path once size reaches max; and this.free.pop() is never reached at all, since this.free.length stays 0 throughout this sequence.

ExplanationTracing the event log in order: the reducer starts at 0, adds 500 for the first deposit event to reach 500, subtracts 200 for the withdraw event to reach 300, then adds 150 for the second deposit event to reach a final balance of 450. This is exactly what distinguishes event sourcing from ordinary state storage: instead of holding a single mutable balance field that gets overwritten with each transaction, the class keeps an append-only log of what happened (events), and the current state is a derived value computed by replaying that log through reduce(). Because nothing is ever mutated in place, the same event log could be replayed to reconstruct the balance at any earlier point, or replayed after a bug fix to recompute corrected totals — the defining advantage of the pattern.

ExplanationEach event in eventLog triggers exactly one call to apply(), and apply() does a single Map.set (for OrderPlaced) or a single Map.get followed by a direct property update (for OrderShipped) — both O(1) operations, since JavaScript's Map is backed by a hash table, not a linear scan or a search tree. Because the loop body performs one such constant-time step per event, running it 50,000 times costs 50,000 x O(1), which is O(n) overall. The scanning claim is wrong because apply() never walks through existing entries — it looks up orderId directly through the hash table. The binary-search-tree claim is wrong because Map lookups don't cost O(log n) in JavaScript engines; hashing gives O(1) access regardless of how many entries are stored. The constant-overall-time claim confuses the cost of one Map operation with the cost of repeating that operation n times in a loop: doing a fixed amount of work 50,000 times takes 50,000 times as long as doing it once, which is exactly what linear growth means.

ExplanationgetNode() searches sortedKeys — the array of ALL virtual node positions on the ring, not just the physical nodes — using the classic binary-search-for-lower-bound pattern: at each step it looks at the midpoint, and if sortedKeys[mid] >= h it records idx and searches the left half (hi = mid - 1), otherwise it searches the right half (lo = mid + 1). Each comparison discards half the remaining candidates, which is exactly what makes binary search O(log m) rather than O(m). Here m = n × replicas = 8 × 100 = 800 total ring entries, so the loop runs at most ⌈log2(800)⌉ = 10 times before lo > hi and the loop exits (since 2^9 = 512 < 800 ≤ 1024 = 2^10). The physical node count n = 8 is irrelevant to the search cost — the algorithm never iterates node-by-node, it iterates over ring positions — so O(n) undercounts the real work. A plain O(m) = 800 linear scan would be correct only for a naive implementation using something like findIndex(), which checks every array element in order instead of halving the range; this code deliberately avoids that. And O(1) is wrong because hashing only locates the key's position on the ring (h = this.hash(key)) — finding which stored ring entry is the nearest one at or after that position still requires a search over the sorted array.

ExplanationCSS specificity is a 3-part tuple (ID count, class count, element/type count) compared left to right — the parts are never added into one combined score. Rule A, `#article.warning`, has one ID selector and one class selector, giving specificity 1-1-0. Rule B, `.content.article-text.warning.critical`, has four class selectors and no ID, giving specificity 0-4-0. Comparing the tuples from the left: Rule A's ID count (1) beats Rule B's ID count (0) immediately, and the comparison stops right there — the class counts (1 vs 4) are never even reached. This is why one ID selector always outranks any number of class selectors: at the ID tier, 1 beats 0 outright regardless of what follows. So the browser applies Rule A, and the paragraph displays red. Source order is only used as a tie-breaker when two rules have the exact same specificity tuple — it does not override a genuine specificity difference. And ID selectors are not automatically promoted to inline-style status; inline `style` attributes form their own separate, higher tier above IDs entirely.

ExplanationWith minimum degree t = 4, a full node holds 2t-1 = 7 keys. The standard B-tree split takes the node's keys in sorted order and identifies the median — the t-th key, the 4th of 7 — to promote into the parent. The remaining six keys divide evenly on either side of that median: the first 3 stay in the original node and the last 3 move into a newly created sibling, so each resulting node ends up with t-1 = 3 keys. If the node was internal, its k+1 = 8 child pointers also split 4 and 4 between the two nodes, keeping every node within the required 3-to-7 key range. A B-tree never leaves a full node unsplit: CLRS-style insertion proactively splits any full node it passes through on the way down, rather than waiting for an 8-key overflow or postponing the split to a later insertion. It also never duplicates a key across the parent and both children — copying keys into every level is a feature of B+ trees, whose internal nodes index copies of leaf keys for fast range scans, not of the plain B-tree described here.

ExplanationSpecificity is the triple (IDs, classes, elements), compared left to right like place-value digits: a rule with a higher ID count always wins outright, no matter how many classes or elements the competing rule has. Computing each rule here: '#main .card p' has one ID (#main), one class (.card), one element (p) -> (1,1,1). '.container .card p' has zero IDs, two classes (.container, .card), one element (p) -> (0,2,1). 'div.container p' has zero IDs, one class (.container), two elements (div, p) -> (0,1,2). 'p' has zero IDs, zero classes, one element -> (0,0,1). Comparing left to right, only '#main .card p' has a nonzero value in the ID column, so it wins immediately regardless of how the class and element columns compare -- the paragraph renders red. Option A is wrong because it compares the class column before checking the ID column; two classes never beat one ID. Option C is wrong because source order (the cascade) only breaks ties between rules with genuinely equal specificity -- it never overrides a real specificity difference. Option D is wrong because specificity comparison applies whenever multiple rules match an element, whether that's one paragraph or a thousand; 'last rule wins' is only the correct shortcut when every competing rule has identical specificity (and no !important).

ExplanationWith m=1000 bits, k=3 hash functions, and n=100 inserted items, the false positive probability is (1-e^(-kn/m))^k = (1-e^(-300/1000))^3 = (1-e^-0.3)^3 ≈ (1-0.741)^3 ≈ (0.259)^3 ≈ 0.0174, or about 1.7%. Checking membership only requires testing the k=3 bit positions produced by the hash functions, giving O(k) = O(3) lookup time no matter how many items were inserted. Because inserting an item only ever sets bits to 1 and a query only ever reads them, an item that was actually inserted will always have all its bits set, so the filter can never report "absent" for it — false negatives are structurally impossible. It can, however, report "possibly present" for an item that was never inserted if other items happened to set the same bits, which is exactly the false positive being calculated here. Claiming equal false-positive and false-negative rates, or O(n) lookup time, misdescribes how the bit array is built and queried. Clearing bits to delete an item is also unsafe in a standard bloom filter, since those same bits are usually shared with other inserted items; safely removing an item requires a counting bloom filter instead.

ExplanationBoth `.card .title` and `.header .title` are descendant selectors built from two class selectors each, so each has a specificity of 0 IDs, 2 classes, and 0 element selectors — an exact tie. When two matching rules in the same cascade layer have identical specificity and neither carries `!important`, CSS does not fall back to alphabetical order of the selector text, and it does not fall back to which class name was written first in the HTML `class` attribute either; it falls back to source order, keeping whichever rule was declared later in the stylesheet. Since `.header .title { color: purple; }` appears after `.card .title { color: green; }`, the browser applies purple to the heading. The claim that the earlier-written rule wins invents a tie-breaking rule that is the exact opposite of how CSS cascade actually works, the alphabetical-ordering claim invents a rule that doesn't exist at all, and the claim that two classes matching on a single element earns "extra" specificity beyond the standard 0-2-0 count is also false — specificity only counts selector components (IDs, classes/attributes/pseudo-classes, and elements/pseudo-elements), never how the underlying HTML groups those classes together.

ExplanationTrace it call by call. Query.authors runs once and returns all 3 author objects from a single database call — that's call #1. Then, because Author.posts is naive (no DataLoader/batching), the GraphQL engine invokes it separately for each of the 3 author objects in the result list, and each invocation issues its own database call to fetch just that author's posts — that's 3 more calls (call #2, #3, #4). Total = 1 (the list query) + 3 (one per-item query) = 4 database calls. This is called the "N+1 problem" because the pattern is always: 1 query to fetch a list of N items, plus N additional queries (one per item) to fetch each item's related data — here N=3 authors, so 1+3=4. The fix is batching (e.g., DataLoader), which collects all 3 pending Author.posts lookups within a single tick and issues one combined "fetch posts WHERE authorId IN (1,2,3)" call instead of 3 separate ones, cutting the total from 4 down to 2 calls. The other options are wrong: GraphQL does not auto-batch resolvers, does not re-verify author ids, and does not auto-compile nested selections into SQL joins — resolver execution strategy is entirely up to what the developer writes.

ExplanationA B-tree with minimum degree t = 3 allows at most 2t − 1 = 5 keys per node, so a full node splits before a new key ever gets inserted into it. Sorting the leaf's keys [10, 20, 30, 40, 50], the median is the 3rd key, 30, which moves up into the parent. The remaining keys divide evenly around it: [10, 20] stays as the left child and [40, 50] becomes the right child, each holding t − 1 = 2 keys as required for a non-root node. Only after this split does the algorithm decide where 25 belongs — since 25 is less than the promoted key 30, it descends into the left child, which becomes [10, 20, 25], still within the allowed 2-to-5-key range. Claiming that the newly inserted key itself gets promoted confuses B-tree splitting with a different insertion strategy; the promoted key is always the median of the existing full node, never the incoming key. Picking 40 as the promoted key miscounts the median position, treating the 4th key of five as the middle instead of the 3rd. And letting the node grow to six keys before splitting ignores the defining B-tree invariant that a node is never allowed to exceed 2t − 1 keys even momentarily during a top-down insertion — that is exactly why the split happens on the way down, before 25 is placed.

ExplanationWalking through the trace step by step: put(1,"A") and put(2,"B") fill the capacity-2 cache with order [1,2] (1 is LRU, 2 is MRU). get(1) hits and moves 1 to the MRU end, giving order [2,1]. put(3,"C") finds the cache full, so it evicts the current LRU key, which is 2, and inserts 3 at the MRU end, giving order [1,3]. get(2) misses since key 2 was just evicted — a miss never touches the linked list, so order stays [1,3]. get(3) hits, but 3 is already at the MRU end, so the order is unchanged: [1,3]. put(4,"D") again finds the cache full, evicts the current LRU key, which is 1, and inserts 4 at the MRU end, giving order [3,4]. At this point key 3 is the least-recently-used of the two remaining keys, so a following put(5,"E") evicts key 3. The claim about key 1 ignores that it was already evicted two steps earlier and mistakenly treats LRU as plain insertion-order (FIFO) eviction. The claim about key 4 reverses the eviction rule, treating the cache as if it discards the most-recently-used entry rather than the least-recently-used one. The claim about key 2 misunderstands what a cache miss does — get(2) returned nothing because key 2 was no longer stored, and a miss cannot refresh or "keep alive" a key that isn't present.

ExplanationFirst string "({[]})": '(' → stack=['(']. '{' → stack=['(','{']. '[' → stack=['(','{','[']. ']' → pairs[']']='[', stack[-1]='[' matches, pop → stack=['(','{']. '}' → pairs['}']='{', stack[-1]='{' matches, pop → stack=['(']. ')' → pairs[')']='(', stack[-1]='(' matches, pop → stack=[]. Return len([])==0 → True. Second string "({[}])": '(' → stack=['(']. '{' → stack=['(','{']. '[' → stack=['(','{','[']. '}' → pairs['}']='{' but stack[-1]='[' ≠ '{'. Return False immediately. The mismatch occurs because '}' tries to close '{' but '[' is actually on top of the stack, so '}' ends up closing over '[' instead.

ExplanationTrace the generator step by step: with a, b = 1, 1, each pass through the loop first yields b, then updates a, b = b, a + b, then increments count. Pass 1 yields 1 (a,b become 1,2). Pass 2 yields 2 (a,b become 2,3). Pass 3 yields 3 (a,b become 3,5). Pass 4 yields 5 (a,b become 5,8). Pass 5 yields 8 (a,b become 8,13). Pass 6 yields 13 (a,b become 13,21), and count now equals 6 so the loop stops. So result = [1, 2, 3, 5, 8, 13]. This is a Fibonacci sequence, but because b (not a) is yielded, the classic leading 1,1 pair collapses into a single first term, shifting which number appears at each position. The last two elements, result[-2:], are [8, 13], and sum(result) totals every element in the full list, not just the sliced pair: 1 + 2 + 3 + 5 + 8 + 13 = 32.

ExplanationTrace: i=0: count=0, candidate=3, count=1. i=1: 1≠3, count=0. i=2: count=0, candidate=2, count=1. i=3: 3≠2, count=0. i=4: count=0, candidate=1, count=1. i=5: 2≠1, count=0. i=6: count=0, candidate=3, count=1. Returns 3. Note: 3 appears 3/7 times (not strict majority), but the algorithm returns the candidate — a second pass would be needed to verify. The question asks what it returns, which is 3.