Operating Systems practice questions

DataAnalyst can read all objects in the production folder, including the sensitive subfolder.

Why it fails: The exhibit's deny ACE on the sensitive subfolder overrides the inherited allow, so DataAnalyst cannot read those objects. The option is tempting because the parent production folder does grant read access, and inheritance normally propagates permissions downward, but an explicit deny at the subfolder level blocks that inheritance.

No one can read from the production folder except DataAnalyst.

Why it fails: The exhibit grants read access to at least one other principal or group in addition to DataAnalyst, so the claim that nobody else can read the production folder is false. It is tempting because DataAnalyst is the named user in the scenario, but the effective permissions include every allow ACE that applies to the folder.

Only DataAnalyst is allowed to read from the entire production folder.

Why it fails: The sensitive subfolder's explicit deny prevents DataAnalyst from reading the entire production folder, so the claim of full read access is wrong. It is tempting because DataAnalyst holds an allow on the parent, but the deny ACE on the child removes that permission for the subfolder.

Use the customer name as the join key.

Why it fails: Customer names are not unique or stable across systems, so joining on them yields duplicate and mismatched rows and misses customers whose names differ. Name matching suits exploratory entity resolution where no identifier exists; here a deterministic key is available and only its data type differs.

Merge using a cross-join and then filter manually.

Why it fails: A cross-join pairs every CRM row with every billing row, producing 50,000-squared combinations with no key relationship, so filtering cannot recover correct pairs. Cross-joins suit generating combinatorial test matrices or calendars, not reconciling records that share a real identifier requiring type harmonisation.

Perform a fuzzy match on the customer address.

Why it fails: Fuzzy matching on address cannot reconcile a GUID against an integer, and addresses are non-unique and inconsistently formatted, so it produces false and missed matches. It is intended for deduplicating messy free-text records lacking a shared identifier, not for joining tables where a deterministic key exists.

Pie chart

Why it fails: A pie chart encodes parts of a single whole at one point in time, so it cannot display monthly progression or the arithmetic subtraction producing net profit. It fits showing a static composition, such as one month's expense breakdown by category, where proportions of a fixed total are the message.

Stacked bar chart

Why it fails: Stacked bars show composition of a total, not the positive and negative contributions that build net profit from revenue, COGS and expenses. Stacked bars suit part-to-whole comparisons such as sales by region within a quarter.

Area chart

Why it fails: An area chart plots cumulative magnitude over time, so stacked series obscure the individual revenue, COGS and expense contributions the analyst must isolate. It suits showing total volume trends, such as cumulative sales across regions, where the aggregate shape matters rather than each component's discrete effect on net profit.

Data virtualization

Why it fails: Data virtualisation creates a logical abstraction layer that queries source systems in real time without physically moving or persisting data, so it cannot perform the transformation step described in the stem, where data is altered before loading into a central repository. This option tempts because it is commonly used for federated reporting across disparate databases, but the scenario explicitly requires a transformation phase that only an ETL (Extract, Transform, Load) approach can execute.

Change data capture

Why it fails: Change data capture replicates only inserted, updated and deleted rows from source databases; it is an extraction technique and performs no transformation before loading. It tempts because CDC genuinely supports consolidating multiple operational sources efficiently, but the stem specifies transformation preceding the load.

ELT (Extract, Load, Transform)

Why it fails: ELT loads raw data into the target before any transformation occurs, contradicting the stem's requirement to transform before loading. It tempts because ELT suits cloud warehouses with abundant compute, where transformation happens after load using the warehouse's own engine rather than in a staging pipeline.

Accuracy: Data is available when needed

Why it fails: Incorrect — this describes Timeliness, not Accuracy.

Completeness: Data values are the same across different systems

Why it fails: Incorrect — this describes Consistency, not Completeness.

Delete any rows with null values without review

Why it fails: Deleting rows with nulls unreviewed destroys valid records and hides systematic gaps, so the assessment never measures completeness or bias. It tempts because nulls often signal defects, yet removal belongs to cleaning after profiling; assessment first quantifies how many values are missing and why.

Immediately load all data into production

Why it fails: Loading unvalidated data into production propagates errors downstream before any profiling, so quality issues reach consumers unchecked. It tempts as the end goal of a pipeline, yet production loading is correct only once assessment has confirmed the dataset meets defined accuracy, completeness and consistency thresholds.

Transform data to match target system without verification

Why it fails: Transforming data before verifying it propagates errors and destroys the ability to trace discrepancies back to the source, so it defeats the assessment. Transformation is tempting because it moves the work toward the target system. It would be appropriate only after profiling and validation confirm the source data's accuracy and completeness.

Social media APIs

Why it fails: Social media APIs expose data owned by external platforms and their users, not data generated within the organisation. They are tempting because APIs feel like a standard acquisition route, and they would be correct when collecting external or public sentiment data.

Government databases

Why it fails: Government databases are external sources published by public agencies, so they supply data originating outside the organisation. They are tempting because they are authoritative and often free, and they would be correct when the question asks about external or third-party data acquisition.

Web scraping

Why it fails: Web scraping extracts content from third-party websites, producing externally sourced data rather than internal records. It is tempting because it is automated and scriptable, and it would be correct when acquiring competitor pricing or public web content.

Create a derived column that concatenates a literal zero with the numeric product code

Why it fails: Concatenating a zero to a numeric value produces a new expression but does not fix the stored column, and it would add an extra zero to values that should not have one. Downstream systems still read the original numeric column. The clean fix is to store the identifier as text in the first place.

Change the column data type to a numeric type with a display format that pads to three digits

Why it fails: A numeric type does not preserve leading zeros at all; the padding is only a presentation format that many tools ignore or that is lost when the value is exported or joined. Downstream matching against a system that stores '007' as text would still fail. The value must be stored as text to retain the leading zero.

Add a check constraint that rejects any product code shorter than three characters

Why it fails: A check constraint validates values but does not change how they are stored. If the column is numeric, the value 7 still has no leading zero, and the constraint would either pass it or reject it without restoring the zero. The underlying problem is the data type, not the presence of validation rules.

A relational OLTP database with third normal form tables

Why it fails: A normalized OLTP relational database enforces rigid schemas and is designed for transactional integrity rather than millions of semi-structured writes per second. Ingesting variable payloads would require constant schema migrations or transformation, creating bottlenecks. This approach does not satisfy the high-velocity, schema-flexible requirements of the fraud detection system.

A graph database optimized for relationship traversal

Why it fails: Graph databases excel at traversing relationships between entities, such as detecting fraud rings, but they are not optimized for ingesting millions of independent event documents per second with flexible schemas. The scenario emphasizes high-volume event storage and semi-structured payloads rather than relationship traversal, so a graph database is not the best fit.

A columnar data warehouse with strict schema-on-write

Why it fails: Columnar warehouses excel at analytical queries but typically enforce schema-on-write and are optimized for batch or micro-batch loads rather than millions of writes per second. Strict schema enforcement would reject or require transformation of semi-structured payloads before ingestion, conflicting with the need for flexible, high-velocity writes in this fraud detection scenario.

Use a CAST function to convert the string dates to a DATE data type, relying on the database's default date format.

Why it fails: Relying on the database's default date format is risky because it may interpret 'DD/MM/YYYY' as 'MM/DD/YYYY', causing errors. CAST does not resolve ambiguity when the source format is non-standard; it simply applies the session's NLS settings, which may not match the data.

Convert all dates to Unix timestamps using a built-in function that automatically detects the format.

Why it fails: Automatic format detection is unreliable for ambiguous dates like '01/02/2023', which could be January 2 or February 1. Unix timestamp conversion functions typically require a known input format; without specifying it, the conversion may fail or produce incorrect results.

Sort the dates as strings and then manually correct any that appear out of order.

Why it fails: Sorting strings does not validate date correctness; invalid dates like '32/01/2023' would still appear. Manual correction is error-prone and not scalable. This method does not address the root cause of inconsistent formats and may leave many records misinterpreted.

Concatenate all raw files into one text file and parse columns positionally using the order from the largest store.

Why it fails: Positional parsing assumes every store uses the same column order, but the scenario states orders differ. Using one store's order will misalign values in other files, producing corrupted staging data that may pass row-count checks but fail semantically. Concatenation also destroys file-level metadata needed for troubleshooting, making root-cause analysis of bad records far harder.

Instruct each store to re-export its file using the corporate header standard before the nightly transfer begins.

Why it fails: Requiring 40 stores to change their export tooling creates a long dependency on external teams and does not help data already received. It also assumes every store can modify its POS export, which is often controlled by a vendor. The acquisition process should tolerate existing source formats rather than block ingestion on upstream changes, so this delays value and risks inconsistent adoption.

Load each file as-is into separate tables and let the BI tool join them by matching column names at query time.

Why it fails: Loading heterogeneous layouts into separate tables pushes the reconciliation burden to every downstream query and report. Column names differ across stores, so name-based joins will fail or silently drop fields, and analysts must remember 40 different schemas. This approach also makes a single normalized staging view impossible without duplicating mapping logic in each report, increasing error risk and maintenance cost.

Apply encryption to all customer ID fields.

Why it fails: Encryption is a security measure to protect sensitive data, but it does not resolve format inconsistencies. Encrypting IDs would actually hinder matching because encrypted values differ. The scenario focuses on integration consistency, not security, so encryption is not an essential data preparation task here.

Remove all records with missing values.

Why it fails: Removing records with missing values may reduce data volume and introduce bias. While handling missing data is important, it is not specifically required to resolve format inconsistencies between the two sources. The core issues are ID and date standardization, not missing data.

Aggregate the data by customer to reduce row count.

Why it fails: Aggregation summarizes data and loses granularity, which is not necessary for resolving format differences. The goal is to integrate and standardize, not to summarize. Aggregating prematurely could obscure details needed for analysis and does not address the format inconsistencies.

Archive both source records and report only the customer identifier without an address attribute

Why it fails: Dropping the address attribute removes the conflict superficially but destroys business value, because billing and operations depend on accurate addresses. Archiving the sources preserves evidence but supplies no rule for choosing a value. The requirement is a consistent, authoritative address across systems, which suppressing the attribute does not deliver.

Allow each consuming system to keep its own address and add a note explaining the discrepancy

Why it fails: Permitting divergent copies institutionalizes the conflict rather than resolving it, and downstream reports will continue to disagree. Documentation of the discrepancy does not create an authoritative value or accountability for correcting it. Since the company needs one trusted customer view, this approach contradicts the purpose of master data governance.

Increase the frequency of the nightly extract so conflicting addresses are overwritten sooner

Why it fails: Refreshing more often does not decide which value is correct; it simply propagates whichever source loads last, making the outcome timing-dependent and unpredictable. Reports could still disagree between loads, and no accountability is established. Because the root problem is conflicting authority rather than staleness, faster extraction leaves the governance gap unresolved.

Data lake

Why it fails: A data lake stores raw data of any format, typically for later schema-on-read processing, but the stem specifies a data warehouse as the target. Data lakes suit exploratory analytics over unstructured or semi-structured data, not the warehouse load-then-transform approach described.

Data mart

Why it fails: A data mart is a subset of a warehouse serving one department's reporting needs; it is a storage scope, not a load-then-transform pattern. Data marts are the right choice when isolating departmental analytics, not when describing where transformations occur relative to loading.

ETL

Why it fails: ETL transforms data before loading it into the warehouse, so raw data never lands first. The stem describes ELT, where extraction and load precede in-warehouse transformation. ETL is chosen when target-side compute is limited or transformations must occur before loading.

Merge all records without deduplication

Why it fails: Merging without deduplication cannot resolve the absent common identifier, so the same patient appears as multiple unlinked records. Probabilistic matching, comparing attributes such as name, date of birth and postcode, is required. Merging suits datasets already sharing a reliable unique key, where consolidation alone is sufficient.

Generate random unique IDs for each system

Why it fails: Generating random unique IDs per system creates disjoint keys, so records for the same patient across hospitals cannot be matched. The technique suits assigning surrogate keys within a single system, not reconciling records lacking a shared identifier. Probabilistic matching, comparing attributes such as name and date of birth, is required here.

Manually match records for all patients

Why it fails: Manual matching cannot scale across multiple hospitals' full patient populations and introduces inconsistent human judgement. Probabilistic or deterministic record linkage using demographic fields is required. Manual review would be correct only for a small candidate set flagged by an automated matching pass.

Remove all transactions with missing customer ID

Why it fails: Dropping rows with missing customer IDs discards valid transactions and shrinks the dataset, rather than reconciling schemas, keys or formats between the two sources. It is tempting because null handling is a genuine data-quality task, and deletion is the right choice when a field is mandatory for the downstream analysis.

Merge data using only store location

Why it fails: Store location is not a shared key between online and in-store records, so joining on it produces mismatched or duplicated rows instead of aligning transactions. It is tempting because location is a legitimate dimension for regional aggregation and reporting, where grouping by store is exactly the intended operation.

Re-platform the mainframe to a modern system

Why it fails: Re-platforming replaces the mainframe itself, a large migration project, rather than acquiring its data. It suits strategic modernisation where the legacy platform is being retired, not a one-off extraction from a system that must keep running.

Use a database gateway

Why it fails: A database gateway translates between protocols but still requires a network-reachable database interface, which the mainframe lacks here. It is tempting because gateways genuinely solve heterogeneous SQL access, and it would be correct if the mainframe exposed a database protocol the gateway could convert.

Manual data entry

Why it fails: Manual data entry cannot scale to mainframe volumes and introduces transcription errors, so it fails the acquisition requirement. It is tempting because it needs no connectivity, and it would be the correct choice only for one-off entry of a handful of records where no automated extraction path exists.

Relational database

Why it fails: A relational database enforces a fixed schema and row-based storage, which struggles with the volume, velocity and schema variability of thousands of raw sensor streams. It is tempting because SQL querying suits analytics. A relational database would be correct for highly structured transactional data needing ACID guarantees and complex joins.

Data mart

Why it fails: A data mart is a curated subset serving one department's reporting, so it cannot ingest thousands of raw device streams or support broad exploratory analytics. It is tempting because marts hold analytics-ready data. A data mart would be correct when a defined business unit needs governed, pre-modelled reporting rather than raw ingestion.

Key-value store

Why it fails: A key-value store retrieves records by key alone, offering no columnar scan, aggregation or schema-on-read needed for exploratory analytics and machine learning over raw sensor data. It is tempting because it scales writes cheaply. A key-value store would be correct for session state, caching or simple lookup workloads.

Timeliness

Why it fails: Timeliness measures whether data reflects the current state at the required moment; duplicate rows can be equally current, so this dimension is untouched. It is tempting because stale source extracts frequently introduce duplicates, yet the dimension duplicates directly breach is uniqueness, not currency.

Consistency

Why it fails: Duplicate records breach uniqueness, not consistency, which concerns whether values conform to the same format, units or rules across systems and records. Consistency is tempting because duplicates often accompany inconsistent formatting, but the dimension directly measured by duplicate detection is uniqueness.

Completeness

Why it fails: Duplicates inflate row counts rather than remove required values, so completeness — the presence of all required attributes — remains unaffected. Completeness is tempting because deduplication projects often clean missing values alongside duplicates, but the dimension duplicates directly violate is uniqueness.

Use a simple crosswalk table based on exact name matches to link records

Why it fails: Exact name matching fails immediately because 'John Smith' and 'Jon Smith' differ, and the ID formats are incompatible, so the crosswalk cannot link records. It is tempting because a crosswalk table is the correct artefact for mapping legacy identifiers to a unified key once matching logic is defined.

Load all data from both systems into a staging table, then run a fuzzy matching algorithm to identify duplicates

Why it fails: Fuzzy matching presumes a common key or comparable field already exists; here the identifiers differ in datatype and format, so no reliable join or match key is available yet. It is tempting because fuzzy matching is genuinely the right tool for reconciling name variations once records are keyed and standardised.

Standardize all customer IDs to a common format (e.g., UUIDs) and then merge the tables

Why it fails: Assigning UUIDs creates new identifiers but does not determine which records represent the same customer, so duplicates persist after merging. It is tempting because surrogate key generation is genuinely required for the unified table, but it must follow entity resolution, not precede it.