A team is provisioning new lower environments from the production database using cloning. All production objects and references reside in the…

When a Snowflake database is cloned, the Data Definition Language (DDL) for all its objects is replicated in the new database. If object definitions use fully qualified names (e.g., productiondb.schema.table), these references are not automatically updated to point to the new cloned database. Consequently, objects in the cloned environment, such as views, secure views, and materialized views, will still point to the original production tables. Similarly, if a table's default value references a sequence using its fully qualified name, the cloned table will incorrectly reference the production sequence. These references must be manually updated to ensure the new environment is isolated.

A. This option is incomplete. It correctly identifies sequences and views but omits materialized views, which are also defined by queries and are subject to the same referencing issues.

C. This option is incorrect because the scenario explicitly states the database has no external references. Storage integrations are used for external stages, making them irrelevant here.

D. This is incorrect. Cloning copies object metadata exactly. Any hardcoded, fully qualified names within object definitions will persist and point to the source, requiring manual updates.

1. Snowflake Documentation: Object Cloning

Section: Introduction to Cloning

Content: "A clone is a writable

independent object that shares the underlying storage with the source object. Changes made to either the source object or the clone are not reflected in the other object." This principle confirms that the cloned object's definition is a copy of the source's definition at the time of cloning. If the source definition contains fully qualified names

the clone will inherit them.

URL: https://docs.snowflake.com/en/user-guide/object-cloning

2. Snowflake Documentation: CREATE