A data analyst wants to clone the 'SALES DB' database to create a development environment called "DEV SALES DB'. The analyst needs to ensure that all schemas within 'SALES DB' , including custom schem

Question

Options

• ACREATE DATABASE CREATE SCHEMA CREATE SCHEMA Repeat for all schemas in
• BCREATE DATABASE DEV SALES DB CLONE SALES DB;
• CBACKUP DATABASE SALES DB TO S3; RESTORE DATABASE DEV SALES DB FROM S3;
• DCREATE OR REPLACE DATABASE DEV SALES DBAS COPY OF SALES DB;
• ECREATE DATABASE DEV SALES DB CLONE SALES DB COPY GRANTS;

• A
  5% (1)
• B
  57% (12)
• C
  24% (5)
• D
  5% (1)
• E
  10% (2)

Explanation

Option B uses Snowflake's native zero-copy cloning syntax - CREATE DATABASE DEV_SALES_DB CLONE SALES_DB; - which replicates the entire database, including all schemas, tables, views, and data, in a single atomic command. The clone shares underlying storage metadata with the source but operates as a fully independent database, meaning changes to either do not affect the other.

Why the distractors fail:

• A requires manually recreating every schema and loading data individually - functional but extremely tedious and error-prone at scale.
• C introduces unnecessary complexity (S3 storage, backup/restore pipeline) when a native clone command exists; it's also slower and costlier.
• D uses invalid Snowflake syntax - AS COPY OF does not exist; the correct keyword is CLONE.
• E adds COPY GRANTS, which would also replicate production-level permissions into the dev environment - generally undesirable and not required by the question's goal of independence.

Memory tip: Think "B for best one-liner" - Snowflake cloning is designed to be a single statement, and option B is the clean, standard form. If you see AS COPY OF or BACKUP/RESTORE, those are red flags for invalid or over-engineered syntax in a Snowflake context.

No community discussion yet for this question.