ARA-C01 Question 275
Single answerBulk file uploadA retail company needs to bulk load 12 TB of historical CSV data from an on-premises data center into Snowflake as a one-time migration. The data center has limited outbound bandwidth, and initial tests using PUT to upload files to an internal stage are taking too long. The architecture team wants the fastest practical approach while minimizing operational complexity and preserving Snowflake-managed ingestion after the files are available in cloud storage. Which approach should the architect recommend?
- A
Continue using PUT from the client host to an internal stage, but increase the warehouse size used for the target table load.
- B
Use Snowpipe Streaming to send the historical files row by row from the data center directly into Snowflake tables.
- C
Use a cloud provider bulk transfer service to physically move the files into cloud object storage, create an external stage on that storage, and then load with COPY INTO.
- D
Split each CSV into many smaller files and repeatedly run INSERT statements from a JDBC client to improve parallelism.
Show answer and explanation
Correct answer: C
Explanation
The key architectural issue is that PUT relies on the client environment's network path to Snowflake. When the source is on premises and bandwidth is limited, direct uploads to an internal stage can become the dominant bottleneck. In these cases, Snowflake best practices favor bulk loading from staged files, and for very large initial migrations, using a cloud provider's physical or bulk data transfer service to place files into cloud object storage is often the fastest and most operationally sound option. After that, Snowflake can use an external stage and COPY INTO to ingest the files efficiently. Warehouse sizing helps with parsing and loading after files are accessible to Snowflake, but it does not solve constrained client upload bandwidth. Similarly, streaming or row-by-row INSERT methods are generally intended for different ingestion patterns and are not ideal for large historical file uploads.
- A. Incorrect.
Incorrect. PUT uploads data from a local file system to an internal stage over the available network connection. If outbound bandwidth from the data center is the bottleneck, increasing warehouse size does not accelerate the file transfer itself. Warehouses affect compute for loading and transformations after files are staged, not the speed of the client-side upload to Snowflake.
- B. Incorrect.
Incorrect. Snowpipe Streaming is designed for low-latency streaming ingestion, not as the preferred mechanism for a very large one-time historical bulk file migration from an on-premises environment. Sending 12 TB row by row would add unnecessary complexity and is generally less suitable than bulk file transfer plus staged loading for this scenario.
- C. Correct.
Correct. For very large one-time migrations where network bandwidth is constrained, the recommended practical pattern is to use the cloud provider's bulk/offline data transfer service to move files into object storage close to Snowflake, then use an external stage and COPY INTO to load the data. This avoids the on-premises network bottleneck of direct PUT uploads while preserving Snowflake-native bulk ingestion from staged files.
- D. Incorrect.
Incorrect. Splitting files can sometimes help parallel loading once files are already staged, but using JDBC INSERT statements for 12 TB of historical data is inefficient and operationally cumbersome compared with staged bulk loading. INSERT-based ingestion is not the best practice for large-scale file-based migration workloads.