A team stores its data as raw Parquet files in a bucket with no table metadata, and queries them by listing paths. What capability do they lose compared with using an open table format?
Select an answer to reveal the explanation.
Short Explanation
A bare path listing is just a guess about what the table contains. An open table format gives you an authoritative record of files, snapshots, schema changes, and safe commits. Without it, you lose atomic commits, snapshot isolation, schema evolution, and reliable concurrent writes.
Full Explanation
The correct answer is the option that identifies atomic commits, snapshot isolation, schema evolution, and reliable concurrent writes as the capabilities lost when querying raw Parquet paths without table metadata. Open table formats maintain metadata describing exactly which data files constitute a table at each snapshot. That metadata enables atomic commits, so readers never observe a partial write; snapshot isolation, so a long query sees a consistent view; schema evolution, so columns can change without rewriting history; and safe concurrent writes through a commit protocol.
The option claiming the team loses the ability to compress data is incorrect because compression is a property of the file format. Parquet compresses regardless of any table layer above it.
The option claiming the team loses the ability to store more than one file per table is incorrect because a directory can obviously hold many files. The problem is that nothing authoritatively states which of them belong to the table right now.
The option claiming nothing significant is lost provided only one writer is ever active is incorrect because a single writer still produces partial states visible to concurrent readers, and still has no mechanism for schema change or time travel.
For the exam, be able to list the four guarantees the format adds over raw files.