DEA-C01 Data Ingestion and Transformation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a crawler for each individual day prefix, such as s3://analytics/events/year=2024/month=05/day=17/, so each day becomes its own table.

  Why it's wrong here

  Creating a separate crawler per day prefix would produce many small tables instead of one partitioned table, which defeats partition pruning and complicates queries. Each table would represent a single day, so a query spanning multiple days would require unions. This approach also creates ongoing maintenance overhead as new days arrive, and it does not leverage Athena's ability to prune partitions within a single table.

• ✓

  Create a crawler with the S3 path pointing to s3://analytics/events/ and enable 'Update all new and existing partitions with metadata from the table' so partition metadata stays current.

  Why this is correct

  The Hive-style year=/month=/day= prefixes are automatically recognized as partitions when the crawler targets the parent prefix. The 'Update all new and existing partitions with metadata from the table' setting ensures that as new date prefixes appear, the crawler adds them and refreshes partition metadata. Athena can then use the partition keys for pruning, scanning only the relevant date ranges instead of the whole bucket.

• ✗

  Create a crawler with the S3 path pointing to s3://analytics/events/ and set the 'Schema change policy' to 'Delete tables and columns' so stale partitions are removed.

  Why it's wrong here

  The 'Delete tables and columns' schema change policy removes tables and columns from the Data Catalog when they are no longer found, which is destructive and unrelated to partition registration. It does not add new partitions for recently created date prefixes, so partition pruning for new data would fail. This setting risks catalog data loss without satisfying the requirement to discover and prune partitions.

• ✗

  Create a crawler with the S3 path pointing to s3://analytics/events/ and enable the 'Add new columns only' option so new partitions are detected automatically.

  Why it's wrong here

  Pointing the crawler at the top-level prefix is correct for discovering the Hive-style partition structure, but 'Add new columns only' is a schema-update policy for table columns, not a partition-discovery setting. It does not control whether new partitions are added. Without the appropriate partition update behavior, newly added date prefixes might not be registered in the Data Catalog, breaking partition pruning for recent data.

Go deeper

Related to this question