Data Engineering Interview Questions: Data Lakes & Lakehouses

A data lake ingests data in its original form, such as files, blobs, and logs, without requiring a predefined schema. Transformation and schema enforcement are deferred until the data is queried, which is called schema-on-read. The options describing cleaned, modeled tables or schema-before-write describe a data warehouse, which uses schema-on-write, and the single proprietary format option is not a property of data lakes.

A data lakehouse merges the two architectures: data is stored in open formats on a lake (cheap, flexible), while a metadata or table layer adds the transactional integrity, schema management, and query performance that a warehouse traditionally provides. The card tests recall of that definition, so the back states the lake-side storage traits and the warehouse-side capabilities it adds.

A traditional data warehouse uses schema-on-write: data is extracted, transformed, and validated against a predefined structure before it lands in the warehouse, so everything stored is structured and conformed. The other three options describe data lakes, which keep raw data in native formats (including unstructured media) on cheap object storage and defer schema until read time.

The name 'lakehouse' signals the blend: the 'lake' part provides the flexible, open-format storage layer, and the 'warehouse' part provides the transactional (ACID), schema-enforcement, and governance features layered on top of that storage.

Data warehouses came first: the approach was formalized in the 1980s and 1990s by Bill Inmon and Ralph Kimball for structured analytics. The term 'data lake' was coined around 2010 for storing large volumes of raw, mostly unstructured data. The 'lakehouse' concept, which combines lake-style storage with warehouse-style management, was popularized around 2020 by Databricks. So the historical order is data warehouse, then data lake, then data lakehouse.

A data lake accepts any data type, including unstructured binary files like images, video, and audio, and keeps them in their original format. A traditional warehouse expects structured, schema-defined tables, so it handles those media files poorly. The other three options (structured relational rows, star-schema fact tables, and OLAP cubes) are the classic workloads a warehouse is designed for, so they are not the answer.

A data lakehouse merges the data lake and the data warehouse. From the data lake it takes open-format, low-cost, scalable storage for structured, semi-structured, and unstructured data; from the data warehouse it takes ACID transactions, schema enforcement, and optimized query performance. The OLTP database and key-value store pairing, the message queue and stream processor pairing, and the data mart and operational data store pairing are not the paradigms a lakehouse is built from.

A data lake stores raw data in its native format and uses schema-on-read, so structure is applied when the data is queried rather than when it is written. A data warehouse, by contrast, enforces schema-on-write and stores structured, pre-modeled data. The question asks for the architecture that has the raw, native-format, schema-on-read property, which is the data lake.

A lakehouse combines ACID transactions with open table formats on cheap object storage, supports BI and ML workloads against the same data, and adds warehouse-style management such as schema enforcement and time travel directly on lake storage. Requiring a proprietary engine load describes the traditional warehouse model that the lakehouse avoids, and banning unstructured data contradicts the lake heritage the lakehouse keeps, so neither is a defining characteristic.

The statement is false. Traditional data warehouses use schema-on-write: data is extracted, transformed, and modeled (for example, into star or snowflake schemas) through ETL pipelines before it is stored. Keeping raw data in its native format and applying structure only when a query runs (schema-on-read) is the defining characteristic of a data lake, not a traditional warehouse.

A data warehouse stores structured, pre-modeled data using schema-on-write and ETL pipelines. This distinguishes it from a data lake, which stores raw data in native formats using schema-on-read. The 'enterprise-wide' qualifier separates a warehouse from a department-scoped data mart.

Schema-on-read is the data lake model: raw data is stored in native format and structure is applied at query time. Schema-on-write is the data warehouse model: data is validated and transformed to a predefined schema at ingest time before it enters the warehouse. The key distinction is therefore when the schema is enforced, either when the data is read or when it is written, which determines where validation cost and data-quality guarantees land in the pipeline.

Data warehouses date to the 1980s and 1990s, built for structured reporting and business intelligence on curated relational data. Data lakes appeared in the 2010s, driven by big data platforms that could store large volumes of unstructured and semi-structured data cheaply. Lakehouses emerged in the late 2010s and 2020s as a response to the lake's lack of reliability, adding ACID transactions and schema enforcement on top of lake storage. So the order is warehouse, then lake, then lakehouse.

In a lakehouse, the data files sit on cheap object storage as Parquet or similar files, and object storage alone offers no multi-file transactions. What adds ACID guarantees is a transactional metadata layer such as Delta Lake, Apache Iceberg, or Apache Hudi, which maintains commit logs, file-version tracking, and snapshot isolation so that readers and writers are isolated and commits are atomic. A columnar file format like Parquet only defines how bytes are laid out within a file, replication only provides durability, and a query optimizer only chooses execution plans, so none of those three provides transactions.

Object storage is immutable at the object level and provides no multi-object transactional guarantees, and Parquet is only a file format. The component that provides ACID behavior is a transactional metadata layer (Delta Lake, Apache Iceberg, or Apache Hudi) that keeps a commit log and snapshot metadata mapping each table version to its set of data files. New commits are added atomically, which gives snapshot isolation and rollback. Neither the storage layer nor the Parquet format alone provides these properties.

A data lakehouse adds a transactional metadata layer, such as Delta Lake, Apache Iceberg, or Apache Hudi, over open-format files that already sit in object storage. That layer provides ACID upserts, time travel, and schema enforcement without copying the data into a separate proprietary store, which is exactly what the scenario requires. A plain data lake stores files cheaply but has no transactional guarantees or built-in schema enforcement. A traditional data warehouse provides ACID and schema management but normally requires ingesting data into its own managed storage engine, which contradicts the no-migration constraint. A data mart is a small aggregated subset for reporting and does not address ACID upserts on raw lake data.

Three architectural differences are key. First, a lakehouse stores data in open file formats (Parquet, ORC) on commodity object storage, whereas a traditional warehouse typically uses a vendor-controlled proprietary storage engine. Second, a lakehouse serves both BI/SQL analytics and ML/data-science workloads from the same storage layer, while a traditional warehouse is optimized primarily for SQL-based analytical querying. Third, an open table-format metadata layer (Delta, Iceberg, Hudi) lets multiple independent compute engines read and write the same data copy, unlike a warehouse that generally exposes data only through its own SQL engine. The claim that a lakehouse eliminates all ETL is false: lakehouses reduce unnecessary data movement and duplication but still require ingestion, cleansing, and transformation pipelines.

Open lakehouse table formats do not rely on a separate lock manager or row-level locking inside Parquet files. Instead, they maintain a metadata layer (Delta Lake's transaction log, Iceberg's catalog + manifest lists, Hudi's timeline) that records which data files make up each table snapshot. Writers perform atomic commits—often a single compare-and-swap operation on a metadata pointer—so that reads always see a consistent snapshot and concurrent writes are serialized, giving ACID guarantees without changing the underlying object store.

The data files must exist before the commit can reference them, so writing them comes before the commit attempt. The conditional write to the transaction log is the commit point, and it fails only if another writer advanced the log version. A retry is only triggered by a failed conditional write, so re-reading the log and retrying comes last. Each adjacent pair has a strict dependency, so the order is total.

The formats rely on optimistic concurrency control: writers stage data files without blocking each other, then compete in an atomic commit to the metadata log, where exactly one commit wins per table version and the others retry after re-validating against the latest state. The atomic-commit guarantee depends on the storage layer offering put-if-absent or atomic rename semantics. Because metadata tracks conflicts at file, partition, or predicate granularity rather than per row, writers touching different rows in the same file collide and one must retry, which a row-locking warehouse would allow. That is the key trade-off: cheap non-blocking writes and simple scaling for batch and append workloads, at the cost of retry overhead and possible aborts under contention on overlapping files.

The Bronze layer is an immutable landing zone whose purpose is to capture raw source data with minimal transformation. Append-only writes preserve the full CDC event history for point-in-time replay, audit, and reprocessing. Allowing the schema to evolve (for example with mergeSchema) lets Bronze absorb additive upstream changes without blocking ingestion. Retaining out-of-contract and malformed records in raw form gives full-fidelity auditability and lets you reprocess from Bronze if downstream logic changes. Enforcing NOT NULL and referential integrity constraints belongs to the Silver layer, where data is cleansed, deduplicated, and conformed; applying them in Bronze would reject records at ingestion and break the capture-everything guarantee that makes Bronze a reliable replay source.

The bug is on line 7, deduped = bronze_df.dropDuplicates(["id"]). dropDuplicates keeps one row per id but does not guarantee which one, and it does not look at updated_at. When an entity has both an INSERT and a later UPDATE in the same batch, the retained row may be the older INSERT, and the MERGE then writes that stale state into Silver. The fix is to rank events per id by updated_at descending with row_number() over a window partitioned by id, keep rank 1, and merge only that row. The MERGE logic on lines 9 to 13 is correct once it receives the latest event per id.

Delta Lake uses optimistic concurrency control. Each writer reads the current table version from the _delta_log, writes its new Parquet files to storage, then attempts to atomically append a new version entry to the transaction log. If the table version has advanced since the read (because another writer committed first), the commit fails on a version-conflict check and the writer must retry from scratch—re-reading data, re-writing files, and re-attempting the commit. This is the standard Delta Lake protocol and the statement is true.

The catalog points to the current table metadata file (a .metadata.json file), which holds the snapshot list and the current-snapshot ID. A commit writes a new metadata file and swaps the catalog pointer atomically, so readers see either the old or the new state. Each snapshot references a manifest list, and the manifest files it points to contain one entry per data file with column-level statistics (lower/upper bounds, null counts) and partition values. Query planners use these manifest entries to skip data files that cannot match a filter. The first blank is 'metadata' and the second is 'manifest'.

The three correct statements are: lakehouses store data in open columnar formats like Parquet or ORC on object storage, while traditional warehouses use proprietary internal formats; the decoupled storage-and-compute model lets several engines (Spark, Trino, Flink) read the same table files, which proprietary warehouses generally do not allow; and lakehouses achieve ACID guarantees through a metadata layer (Delta log, Iceberg catalog, Hudi timeline) over object-store files, whereas a warehouse handles transactions inside its own storage engine. The statement claiming strictly stronger consistency is false: optimistic concurrency control gives comparable, not stronger, guarantees than warehouse locking, and it tends to perform worse under heavy write contention. The statement that lakehouses fully eliminate a raw lake is too absolute, since lakehouses reduce but do not replace a raw lake for all unstructured or schemaless use cases.