ADA-C01 Question 236
Single answerCreate and manage iceberg tablesA data platform team wants to expose curated sales data to both Snowflake users and external engines that read Apache Iceberg tables from cloud object storage. The team must create a new table in Snowflake that stores its metadata and data files in an external volume, uses Snowflake catalog integration for Iceberg metadata management, and supports ongoing DML from Snowflake. Which approach should the Snowflake administrator take?
- A
Create a standard Snowflake table, then enable Iceberg compatibility by setting a table parameter that publishes Parquet files to the external stage.
- B
Create a Snowflake-managed Iceberg table and specify an external volume and catalog = 'SNOWFLAKE' so Snowflake manages the Iceberg metadata and writes files to object storage.
- C
Create an external table on top of the object storage location and convert it to an Iceberg table using ALTER TABLE SET TYPE = ICEBERG.
- D
Create an Iceberg table that uses a REST catalog hosted outside Snowflake, then use Snowflake DML to keep the external catalog synchronized automatically.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to create a Snowflake-managed Iceberg table backed by an external volume and Snowflake as the catalog. This design is used when Snowflake should manage Iceberg metadata and support data modifications from Snowflake while storing the actual files in customer cloud storage. In practice, administrators first create and configure an external volume that points to the cloud storage location, then create the Iceberg table with Snowflake-managed catalog settings. This differs from external tables, which query files in place and do not provide Iceberg table management semantics. It also differs from externally managed Iceberg tables, where a catalog such as REST, Glue, or another supported catalog manages metadata outside Snowflake. Snowflake documentation on Apache Iceberg tables, external volumes, and Snowflake-managed Iceberg tables describes these distinctions and the required object configuration.
- A. Incorrect.
Incorrect. Standard Snowflake tables do not become Iceberg tables by enabling a compatibility parameter, and Snowflake does not support simply publishing a standard table as Iceberg by toggling a setting. Iceberg tables are created explicitly using Iceberg table syntax and associated configuration such as an external volume. This option reflects a common misconception that Iceberg is just a storage format switch for standard tables.
- B. Correct.
Correct. A Snowflake-managed Iceberg table is the appropriate choice when Snowflake should support ongoing DML and manage the Iceberg metadata. In this model, the administrator creates the Iceberg table with an external volume so data and metadata files reside in cloud object storage, while Snowflake acts as the catalog using the Snowflake catalog option. This aligns with the requirement for Snowflake-managed metadata and Snowflake-based writes.
- C. Incorrect.
Incorrect. External tables and Iceberg tables are different object types with different management models. Snowflake does not support converting an external table into an Iceberg table with a simple ALTER TABLE type change. External tables are used to query files in place, while Iceberg tables rely on Iceberg metadata structures and table lifecycle operations.
- D. Incorrect.
Incorrect. If the requirement is for Snowflake catalog integration and Snowflake-managed metadata, using an external REST catalog does not meet that requirement. Also, support for DML depends on the Iceberg table management model; the scenario specifically calls for Snowflake to manage the catalog metadata, not a third-party catalog. This option mixes valid Iceberg concepts in a way that does not satisfy the stated design goals.