DEA-C01 Practice Question 16: Iceberg Row Level Delete
AWS Certified Data Engineer – Associate (DEA-C01) · Test 2 · question 6 of 10
A data lake stores five years of customer interaction events as Parquet files in Amazon S3. The table is registered in the AWS Glue Data Catalog as a standard Hive-style table partitioned by month. Under a data privacy regulation, the company must erase all rows for a specific customer within 30 days of a request, and it receives hundreds of requests each month. Today an engineer runs a custom Spark job that reads each affected partition, filters out the customer's rows, and overwrites the partition. Concurrent Amazon Athena queries sometimes fail or return incomplete results while a partition is being overwritten.
Which approach addresses both the operational effort and the query failures?
Show answer and explanation
Answer:
This is the problem open table formats were built to solve. Apache Iceberg manages a table's files through metadata and supports "record-level insert, update, delete, and time travel queries". Athena can run INSERT, UPDATE, DELETE, and MERGE INTO directly against Iceberg tables. Its UPDATE and DELETE statements follow the Iceberg v2 row-level position delete spec and "enforce snapshot isolation". An erasure request becomes one SQL statement in place of a custom partition-rewrite job. Each transaction commits a new snapshot atomically, so a concurrent Athena query sees either the table before the delete or after it, never a half-rewritten partition. In practice you would also compact the table (OPTIMIZE) and expire old snapshots (VACUUM), so the deleted rows are physically removed from older data files and are no longer reachable through time travel.
Option A works against the goal. Object Lock exists to *prevent* deletion and overwrites. It does nothing to make a rewrite atomic, and in governance mode it would block the erasure pipeline itself unless someone bypassed it.
Option B changes the tool, not the approach. It is still a whole-partition rewrite followed by a swap of table locations. On a Hive-style table that swap is not transactional, so readers can still catch it midway. Doing this for hundreds of requests a month is the same manual effort.
Option C deletes by object age, not by customer. It would destroy almost all five years of history while doing nothing to target a particular customer's rows.
References: Query Apache Iceberg tables; Update Iceberg table data