Question 11

A cloud storage system uses a trie to index filenames. Users frequently search for partial matches (e.g., "doc" for "document.pdf"). The current implementation traverses the entire trie for wildcard queries, causing latency. Which optimization reduces search time without increasing space complexity?

• Precompute all possible wildcard combinations in a lookup table.
• Use a suffix automaton to handle wildcards.
• Store filenames in a hash table for O(1) lookups.
• Implement a compressed trie (Radix Tree) with lazy expansion for wildcards.

---

Question 12

A ranking service receives score streams containing long equal-value plateaus, sharp drops, and occasional late spikes. The production routine may return only the length, while the audit routine separately reconstructs examples, so the helper below must preserve the compact state used by the length path without storing parent links.

function lengthPath(a):
    if size(a) == 0: return 0
    
    temp = [a[0]]
    len = 1
    
    for i = 1 to size(a)-1:
        if a[i] > last(temp):
            append(temp, a[i])
            len = len + 1
        else:
            fix(temp, a[i])
            
    return len

function fix(temp, x):
    # ...

Which replacement for fix keeps lengthPath correct for every plateau-heavy and drop-heavy stream?

• return first index k where tails[k] >= x function fix(temp, x): p = binarySearch(temp, x, 'lower_ge') temp[p] = x
• return last index k where tails[k] < x function fix(temp, x): p = binarySearch(temp, x, 'floor_lt') temp[p] = x
• return first index k where tails[k] > x function fix(temp, x): p = binarySearch(temp, x, 'upper_gt') temp[p] = x
• return last index k where tails[k] == x function fix(temp, x): p = binarySearch(temp, x, 'prior_eq') temp[p] = x

(Note: The first line in the options seems to be a descriptive comment preceding the function definition)

---

Question 13

A system designed for high-frequency trading experiences micro-bursts of high latency during peak trading hours. Analysis of kernel trace logs shows brief periods where a single high-priority thread is constantly preempted by other, seemingly lower-priority, threads. What scheduling issue is likely occurring?

• The CPU cache is thrashing due to rapid context switching between unrelated processes.
• The system's tickless kernel configuration is causing inaccurate timer interrupts.
• Priority inheritance mechanism is misconfigured, leading to lower-priority threads temporarily inheriting higher priority.
• The high-frequency trading application is I/O bound, frequently yielding the CPU.

---

Question 14

An Oracle data-warehouse summary is backing a sales dashboard, but checkout commits have started slowing down during peak insert bursts. The materialized view definition was chosen to minimize refresh work per cycle, and fast-refresh eligibility has already been validated with the required logs on the detail tables. Business now accepts bounded staleness during the day, but does not want every sales transaction to pay the refresh cost at commit time. Architects want the smallest change that preserves incremental maintenance when possible while shifting refresh work away from OLTP commits.

CREATE MATERIALIZED VIEW SalesSummary
BUILD IMMEDIATE
REFRESH FAST
ON COMMIT
AS
SELECT p.product_id,
       p.product_name,
       SUM(s.sale_amount) AS total_sales
FROM products p
JOIN sales s
  ON p.product_id = s.product_id
GROUP BY p.product_id, p.product_name;

Which redesign most directly fits that requirement?

• Keep incremental refresh but move it to ON DEMAND, then run refresh on a defined cadence so write transactions stop paying commit-time refresh cost.
• Switch to COMPLETE ON COMMIT, because full recomputation removes log-dependency overhead and therefore lowers write-path latency under frequent sales inserts.
• Keep ON COMMIT and change to FORCE, because Oracle will skip unnecessary refresh work automatically when detail-table changes are too small to matter.
• Replace the materialized view with a normal view, because deferred execution avoids staleness entirely while still keeping aggregate-query cost off the base tables.

---

Question 15

A banking DW requires 'Snapshot Isolation' to ensure consistent reporting while ETL jobs are running. Long running analytical queries are failing with "Snapshot too old" errors during heavy update windows. Which architectural change resolves the read consistency issue without blocking the write operations?

• Implement pessimistic locking on the target tables to prevent ETL writes while readers are active.
• Reduce the transaction isolation level to Read Committed to allow readers to see partial updates.
• Switch the ETL process to an append-only model and use a view to filter for the latest version of records.
• Partition the table by date and only allow the ETL process to write to the current day's partition.