ADA-C01 Question 50
Single answerManage cloned objects and their impact on granted privilegesA Snowflake administrator creates a zero-copy clone of the PROD_DB database as UAT_DB so testers can validate a release. In PROD_DB, the ANALYST role has SELECT on several tables, and the ETL role has OWNERSHIP on a schema. After the clone is created, testers report they cannot query objects in UAT_DB even though they can see the database. The administrator wants to understand how privileges behave for cloned objects and what must be done next. Which statement is correct?
- A
All object privileges from PROD_DB are automatically copied to the corresponding objects in UAT_DB, so the issue must be caused by missing warehouse privileges.
- B
Existing grants on child objects in PROD_DB are not automatically reproduced on the cloned child objects in UAT_DB, so privileges must be granted again on the clone as needed.
- C
If COPY GRANTS is specified during the database clone, all privileges on all contained schemas and tables are copied to UAT_DB automatically.
- D
Cloning a database transfers OWNERSHIP of all cloned objects to the same roles that owned the source objects, so no privilege changes are required after cloning.
Show answer and explanation
Correct answer: B
Explanation
The key administrative point is that zero-copy cloning reproduces object definitions and data state efficiently, but it does not automatically preserve the effective privilege model for contained cloned objects in the way many administrators expect. In practice, a cloned database or schema often requires explicit re-granting of privileges to roles that should access the cloned environment. This is especially important when promoting production-like data into lower environments such as UAT, where access patterns often differ from production. Snowflake documentation on cloning and access control emphasizes evaluating grants separately for cloned objects and understanding that OWNERSHIP and other privileges on source objects do not simply carry over to the new cloned object hierarchy. Best practice is to validate role access after cloning and apply least-privilege grants explicitly for the target environment.
- A. Incorrect.
Incorrect. A common misconception is that cloning reproduces the full privilege model of the source. While the cloned database object itself can be granted privileges, grants on contained objects are not simply carried over as active grants to the cloned child objects in the new hierarchy. If users can see the database but cannot query tables, missing privileges on the cloned schemas/tables are a likely cause, not necessarily warehouse access.
- B. Correct.
Correct. When objects are cloned, the data and structure are copied using zero-copy semantics, but existing grants on source child objects do not automatically become grants on the cloned child objects. After cloning, administrators typically need to re-grant privileges on the cloned schemas, tables, views, and other securable objects, or use future grants/governance patterns appropriate for the target environment.
- C. Incorrect.
Incorrect. COPY GRANTS applies in specific contexts such as replacing or duplicating certain individual objects, but it does not make a database clone inherit every grant on all contained child objects from the source. Choosing this option reflects confusion between object-level COPY GRANTS behavior and privilege handling for cloned database hierarchies.
- D. Incorrect.
Incorrect. OWNERSHIP is a special privilege and does not remain with the original owning roles on the source hierarchy simply because an object is cloned. The clone creates new objects, and administrators must evaluate and assign the necessary privileges in the target environment. Assuming ownership mappings persist unchanged is a security risk and not how cloned privilege management works.