ADA-C01 Question 251
Single answerCreate and manage EXTERNAL_VOLUME with Iceberg tablesA data platform team wants Snowflake-managed Apache Iceberg tables to store their table metadata and data files in an Amazon S3 bucket owned by the company. The security team requires least-privilege access and wants Snowflake to use a dedicated IAM role for writes to the bucket. As the Snowflake administrator, you need to configure the storage location so developers can create Iceberg tables without embedding cloud credentials in each table definition. Which action should you take?
- A
Create an EXTERNAL_VOLUME that points to the S3 location, configure the storage provider and allowed locations, grant the Snowflake-generated IAM user or role access to the bucket, and reference that EXTERNAL_VOLUME when creating the Iceberg tables.
- B
Create an external stage on the S3 bucket with STORAGE_INTEGRATION, then create Iceberg tables that use the stage name instead of an EXTERNAL_VOLUME because Iceberg metadata is managed through stages.
- C
Create a FILE FORMAT for Parquet and assign it to the database so Snowflake can automatically manage Iceberg metadata files in S3 without any EXTERNAL_VOLUME.
- D
Create a secondary database in the target region and replicate it to S3, because replicated databases automatically provide the external storage location required for Snowflake-managed Iceberg tables.
Show answer and explanation
Correct answer: A
Explanation
The key administrative concept is that Snowflake-managed Iceberg tables stored in customer-owned object storage require an EXTERNAL_VOLUME. This object encapsulates the external cloud storage location and the authorization model Snowflake uses to access it. For AWS, the normal pattern is to create the EXTERNAL_VOLUME, specify the S3 base location, and then update the AWS-side IAM policy/trust relationship so Snowflake can read and write the Iceberg metadata and data files. This is preferable to embedding credentials in individual table definitions and supports centralized administration and least-privilege access. A common misconception is that stages or storage integrations are interchangeable with EXTERNAL_VOLUME for Iceberg; they are not. Snowflake documentation for Apache Iceberg tables and CREATE EXTERNAL VOLUME distinguishes these objects clearly: EXTERNAL_VOLUME is the required object for Snowflake-managed Iceberg tables that store files in external cloud storage.
- A. Correct.
Correct. For Snowflake-managed Iceberg tables that use external cloud storage, Snowflake requires an EXTERNAL_VOLUME object to define and manage the external storage location. In AWS, the administrator configures the EXTERNAL_VOLUME with the storage base URL and related settings, then grants the Snowflake-provisioned identity access to the S3 bucket using a dedicated IAM role or trust configuration. After that, developers can reference the EXTERNAL_VOLUME in CREATE ICEBERG TABLE statements, avoiding embedded credentials and aligning with least-privilege practices.
- B. Incorrect.
Incorrect. External stages and storage integrations are used for data loading/unloading and external tables, but they are not the required storage abstraction for Snowflake-managed Iceberg tables stored in external object storage. Snowflake-managed Iceberg tables use EXTERNAL_VOLUME, not a stage name, to define where metadata and data files are stored.
- C. Incorrect.
Incorrect. A file format object does not provide cloud storage authorization or a managed storage location. Although Iceberg tables commonly store data in Parquet, defining a FILE FORMAT does not replace the need for an EXTERNAL_VOLUME. Snowflake still needs an authorized external volume to write metadata and data files to S3.
- D. Incorrect.
Incorrect. Database replication does not create or substitute for the external object storage configuration needed by Snowflake-managed Iceberg tables. Replication is for Snowflake database objects and failover/disaster recovery scenarios, not for defining where Iceberg table files are stored in cloud object storage.