ARA-C01 Question 287
Select 3Iceberg tables (managed and unmanaged)A retail company stores curated product data in Apache Iceberg format on external object storage so that both Snowflake and a Spark-based pricing platform can read the same tables. The architects want Snowflake to query the data without taking ownership of the table files, and they also want changes made by Spark to become visible in Snowflake after the Iceberg metadata is refreshed. Which TWO design choices best meet these requirements?
- A
Create unmanaged Iceberg tables in Snowflake that reference the external catalog and external storage location used by Spark.
- B
Create Snowflake-managed Iceberg tables so Snowflake controls the table lifecycle while Spark continues to update the same metadata files directly.
- C
Use an external volume so Snowflake can access the external cloud storage where the Iceberg table data and metadata files reside.
- D
Convert the Iceberg tables to standard Snowflake native tables because only native tables can reflect updates from external engines after refresh.
- E
Configure Snowflake to refresh the unmanaged Iceberg table metadata so newly committed snapshots from Spark are recognized by Snowflake.
Show answer and explanation
Correct answers: A, C, E
Explanation
The best solution is to use unmanaged Iceberg tables with access to the external storage and a metadata refresh process so Snowflake can see updates committed by Spark. This aligns with the core distinction between managed and unmanaged Iceberg tables in Snowflake: managed Iceberg tables are for cases where Snowflake manages the table, while unmanaged Iceberg tables are for externally managed Iceberg datasets that Snowflake reads. In real-world architectures where multiple engines share the same Iceberg table, architects typically keep the table in external object storage, configure Snowflake access through an external volume, and refresh metadata so Snowflake recognizes the latest Iceberg snapshots. These choices follow Snowflake guidance for interoperating with externally managed Apache Iceberg tables and for accessing Iceberg data stored outside Snowflake.
- A. Correct.
Correct. Unmanaged Iceberg tables are intended for scenarios where Snowflake reads externally managed Iceberg tables rather than owning the data and metadata lifecycle. This matches the requirement that Snowflake must not take ownership of the table files and that another engine such as Spark can continue to write and commit changes.
- B. Incorrect.
Incorrect. Snowflake-managed Iceberg tables are appropriate when Snowflake manages the table, including writes and lifecycle coordination through supported catalog/storage patterns. That does not fit the stated requirement that Spark continues to update the table metadata directly while Snowflake avoids owning the files. Choosing this option reflects the misconception that managed Iceberg tables are the best fit for all Iceberg interoperability scenarios.
- C. Correct.
Correct. An external volume is used so Snowflake can securely access data and metadata files in external cloud storage for Iceberg tables. In this scenario, because the Iceberg data remains in object storage shared with Spark, Snowflake needs configured access to that storage.
- D. Incorrect.
Incorrect. Standard Snowflake native tables are not the right choice when the business requirement is to share the same Apache Iceberg table with external engines like Spark. Native tables are internal Snowflake objects and do not provide the same open-table interoperability model. This option reflects the misconception that converting to native tables simplifies cross-engine visibility.
- E. Correct.
Correct. For unmanaged Iceberg tables, Snowflake can recognize externally committed changes after the Iceberg metadata is refreshed. This is essential when Spark writes new snapshots and Snowflake needs to query the latest committed table state. Without refresh, Snowflake may continue using previously known metadata.