ADA-C01 Question 539
Single answerStages, pipes, and clones objectsA data engineering team loads CSV files from an internal named stage into table RAW.SALES using a Snowpipe object named PIPE_SALES. To validate a new file format definition without affecting production, the Snowflake administrator creates a zero-copy clone of schema RAW as RAW_TEST. The clone contains the table, stage, and pipe definitions. Shortly after the clone is created, new files are uploaded only to the original named stage @RAW.INT_STAGE. The administrator wants to test loading those newly arrived files into RAW_TEST.SALES with minimal manual effort and without disrupting the production pipe. Which action should the administrator take?
- A
Resume RAW_TEST.PIPE_SALES, because a cloned pipe automatically begins loading newly arrived files from the original stage into the cloned table
- B
Execute ALTER PIPE RAW_TEST.PIPE_SALES REFRESH, because the cloned pipe is paused by default and can load eligible files from the referenced stage into the cloned target table after being refreshed
- C
Recreate the stage inside RAW_TEST, because cloned stages do not retain references to the original stage location or file metadata
- D
Clone the pipe again after the files arrive, because pipes only detect files that were present at the time the clone was created
Show answer and explanation
Correct answer: B
Explanation
This scenario tests how cloning interacts with stages and Snowpipe. In Snowflake, schemas can be zero-copy cloned, and cloneable child objects such as tables, named stages, and pipes are included in the clone definition. However, a cloned pipe is created in a paused state. That behavior is important in administrative workflows because it prevents accidental duplicate or unintended loading immediately after cloning. To test ingestion in the cloned environment, the administrator should operate on the cloned pipe rather than the production pipe, and use ALTER PIPE ... REFRESH to load eligible files from the referenced stage into the cloned target table. Also note that cloning a stage clones the stage object definition, not a separate copy of the underlying staged data files. This question reflects Snowflake best practices for isolating testing from production while minimizing effort and risk.
- A. Incorrect.
Incorrect. When a pipe is cloned, the cloned pipe is created in a paused state. It does not automatically resume or begin loading files. In addition, simply resuming a cloned pipe is not sufficient to backfill already available files unless the pipe is refreshed or otherwise triggered appropriately. This option reflects the common misconception that cloned ingestion objects immediately behave like their sources.
- B. Correct.
Correct. A cloned pipe is paused by default. To test loading into the cloned table without affecting production, the administrator should use the cloned pipe in RAW_TEST and refresh it so Snowflake evaluates eligible files in the referenced stage and enqueues them for loading into RAW_TEST.SALES. This approach preserves the production pipe while allowing validation in the cloned environment with minimal manual effort.
- C. Incorrect.
Incorrect. Named stages are cloneable objects, and their definitions are retained in the clone. For an internal named stage, the stage object itself is cloned; the issue is not that the stage definition is lost. Recreating the stage is unnecessary and adds operational overhead. This distractor targets confusion between cloning stage metadata and copying staged files.
- D. Incorrect.
Incorrect. There is no requirement to re-clone the pipe after new files arrive. A cloned pipe can be used after cloning, but because it is paused by default, it must be explicitly managed. The timing of file arrival relative to the clone operation does not require the pipe to be cloned again.