You are using a virtual warehouse 'X-SMALL' to load data from a large CSV file (50GB) residing in an external stage into a Snowflake table. During the data loading process, you observe that the wareho

Question

Options

• AIncrease the virtual warehouse size to 'MEDIUM' or larger.
• BSplit the large CSV file into smaller files and load them in parallel.
• CUse the 'VALIDATE' function before loading to ensure data quality, which will speed up the loading
• DPartition the Snowflake table based on a relevant column in the CSV file before loading the data.
• ECompress the CSV file using gzip or bzip2 before uploading it to the external stage.

• A
  53% (10)
• C
  16% (3)
• D
  32% (6)

Explanation

Scaling up the warehouse (A) gives the loading process more compute resources, directly reducing execution time when CPU is the bottleneck. Splitting the CSV into smaller files (B) enables Snowflake to parallelize ingestion across multiple threads - Snowflake's COPY INTO command is designed to load many small files concurrently, so one 50GB file is far less efficient than hundreds of 100–200MB chunks. Compressing files with gzip or bzip2 (E) reduces the data transfer volume from the external stage, cutting I/O time, and Snowflake natively decompresses on the fly.

Why the distractors are wrong:

• C is wrong because VALIDATE is a post-load audit function that simulates a load and reports errors - it adds overhead rather than speeding anything up.
• D is wrong because Snowflake uses automatic micro-partitioning and does not support manual table partitioning like traditional databases; you cannot pre-partition a Snowflake table to speed up a bulk load.

Memory tip: Think "Scale, Split, Shrink" - scale the warehouse up, split the file up, and shrink the file size via compression. Any option that adds a pre-load validation step or assumes Snowflake works like a traditional RDBMS with manual partitioning is a trap.

No community discussion yet for this question.