ADA-C01 Question 49
Single answerManage cloned objects and their impact on granted privilegesA Snowflake administrator is preparing a UAT environment by cloning the PROD_FIN database into UAT_FIN. In PROD_FIN, the ANALYST role has SELECT on several tables and USAGE on schemas, and a custom role ETL_ROLE has INSERT and UPDATE on a subset of tables. The administrator executes CREATE DATABASE UAT_FIN CLONE PROD_FIN; and then asks whether application roles will still be able to access the cloned objects. Which statement best describes how privileges are handled for the cloned database and its child objects?
- A
All object privileges granted on objects in PROD_FIN are automatically copied to the corresponding cloned objects in UAT_FIN, so the same roles retain access without additional grants.
- B
Only future grants defined in PROD_FIN are copied to UAT_FIN; existing object grants are not copied, so access must be re-granted on all cloned objects.
- C
The cloned database inherits ownership from the source database owner, but existing grants on the source objects are not copied to the cloned objects unless they are explicitly re-granted.
- D
Privileges granted directly on the source database container may need to be granted again on UAT_FIN, but grants on cloned child objects are copied with those objects, preserving access for roles on the corresponding cloned objects.
Show answer and explanation
Correct answer: D
Explanation
This question tests a key administrative nuance of cloning in Snowflake: cloned objects preserve many of the source object's properties, including grants on child objects, but the clone itself is a new object with its own privilege model. Practically, when cloning a database or schema, object-level privileges on contained objects are copied to the cloned versions. However, the new parent container, such as the cloned database UAT_FIN, does not automatically confer the same database-level grants that existed on PROD_FIN. Therefore, a role might still have privileges on a cloned table but be unable to access it until it also has the necessary USAGE privileges on the cloned database and schema. This aligns with Snowflake documentation on cloning considerations and access control behavior for cloned objects. Best practice is to validate both container-level privileges and copied child-object grants after cloning, especially in UAT or DR provisioning workflows.
- A. Incorrect.
Incorrect. This overgeneralizes privilege behavior. In Snowflake, grants on cloned child objects such as schemas, tables, and views are copied with the cloned objects, but grants on the cloned container itself are not automatically preserved in the same way. A role that had privileges on PROD_FIN as a database does not automatically receive equivalent privileges on UAT_FIN unless granted separately.
- B. Incorrect.
Incorrect. This confuses future grants with existing grants. Existing grants on child objects are copied when those objects are cloned. Future grants are not what preserves current access to the cloned objects. Also, future grants are metadata on the container and should be evaluated separately rather than assumed to be the only grants that carry over.
- C. Incorrect.
Incorrect. While ownership of the new cloned database is assigned as part of clone creation, this statement is wrong because it says existing grants on source objects are not copied. For most cloned child objects, granted privileges are copied to the clone, so roles can retain access to corresponding cloned tables, views, and schemas. The misconception is treating cloning like a fresh object deployment with no ACL metadata carried forward.
- D. Correct.
Correct. In Snowflake, when a database or schema is cloned, grants on the child objects contained in the clone are copied with those objects. However, the new cloned container is a separate object, so privileges on the source database itself do not automatically apply to the new database. As a result, roles may still have access to cloned tables or schemas if the relevant object grants were copied, but database-level access such as USAGE on UAT_FIN may need to be granted explicitly.