ARA-C01 Question 162
Select 2Data lake and environmentsA company is modernizing its analytics platform using Snowflake and wants to keep raw files in cloud object storage as the system of record. The architecture team must support separate DEV, TEST, and PROD environments while minimizing data movement and ensuring that production data is not accidentally modified by development workloads. Analysts in each environment need SQL access to the same underlying raw Parquet files in the data lake, and data engineers want environment-specific transformations and secure promotion to production. Which TWO actions should the architect recommend?
- A
Create separate external stages and external tables for each environment that point to the same cloud storage locations, and isolate environment-specific transformed data inside Snowflake databases and schemas.
- B
Copy the raw Parquet files from the data lake into separate cloud storage prefixes for DEV, TEST, and PROD so each Snowflake environment has physically isolated raw data.
- C
Use zero-copy cloning to promote curated Snowflake databases or schemas from lower environments to higher environments after validation, instead of reloading the raw data lake files for each promotion.
- D
Store DEV-transformed outputs back into the same production raw data lake folder so external tables in all environments immediately reflect the latest schema changes.
- E
Replace the external tables with temporary tables in each environment because temporary tables provide better cross-environment consistency for shared access to the same object storage files.
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to share immutable raw data in the cloud data lake through external stages and external tables, while isolating DEV, TEST, and PROD using Snowflake databases, schemas, roles, and compute resources for downstream processing. This avoids unnecessary duplication of the raw data lake and supports a common architecture where object storage remains the system of record. For promotion of validated transformed objects between environments, zero-copy cloning is the preferred Snowflake capability because it is fast, storage-efficient, and operationally simpler than reloading the same raw files. Snowflake documentation and best practices around external tables, stages, and zero-copy cloning support these patterns: external tables are intended for querying data in external storage, and cloning is designed for rapid environment provisioning and release promotion. The key architectural principle is to keep raw lake data protected and read-only while using Snowflake-native features to manage environment separation and promotion safely.
- A. Correct.
Correct. External tables can reference data stored in cloud object storage through external stages, allowing multiple Snowflake environments to query the same raw files without duplicating them. This aligns with a common data lake pattern where object storage remains the system of record. Environment isolation should be applied to downstream curated or transformed objects inside Snowflake rather than by repeatedly copying unchanged raw files. Separate databases, schemas, roles, and warehouses help keep DEV, TEST, and PROD logically isolated while still using shared raw data appropriately.
- B. Incorrect.
Incorrect. Physically copying the same raw files into separate cloud storage prefixes for each environment increases storage, synchronization, and operational complexity. It also undermines the goal of minimizing data movement. In most architectures, the raw zone in the data lake is treated as immutable and shared as a read-only source, while environment separation is enforced through Snowflake objects, access control, and downstream processing layers. Physical duplication may be justified in special regulatory cases, but it is not the best recommendation for this scenario.
- C. Correct.
Correct. Zero-copy cloning is a Snowflake best practice for promoting validated databases, schemas, or tables across environments because it is fast and storage-efficient. It allows teams to create production-ready copies of curated objects without re-ingesting the raw lake data. This supports controlled release management and reduces risk compared with rebuilding production directly from development logic each time. Cloning is especially useful for promoting transformed datasets and application schemas after testing has been completed.
- D. Incorrect.
Incorrect. Writing development outputs into the same production raw folder violates sound lake design and environment isolation principles. The raw layer should generally be immutable and protected, especially if it is designated as the system of record. Mixing development-generated files with production raw data creates governance, lineage, and reliability issues and can cause external tables across environments to expose unvalidated or incorrect content. This option reflects the misconception that sharing a storage location is equivalent to safe environment promotion.
- E. Incorrect.
Incorrect. Temporary tables are session-scoped Snowflake objects and are not a replacement for external tables when the requirement is to query shared files in object storage. They do not provide persistent metadata over data lake files and are not intended for cross-environment consistency. External tables are specifically designed to expose file-based data in external stages for SQL querying. This option confuses internal transient/session objects with external metadata definitions over data lake storage.