DEA-C02 · Question #72
A Data Engineer has been asked by the development team to create a snapshot of production data from the ABC database into the developer account. None of the data is Personal Identifiable Information (
The correct answer is A. The Data Engineer did not grant on the schema and on the tables in the. Option A is correct because Snowflake Data Sharing requires explicit privilege grants at every level of the object hierarchy within the share. The engineer granted USAGE on the database to the share, but never granted USAGE on the schemas or SELECT on the tables - without these,
Question
A Data Engineer has been asked by the development team to create a snapshot of production data from the ABC database into the developer account. None of the data is Personal Identifiable Information (PII) or sensitive. Both accounts are in the same region and use the same cloud provider. The Engineer performs these steps:
In the production account:
use role accountadmin; create database ABC_CLONE clone ABC; create share ABC_SHARE; grant usage on database ABC_CLONE to share ABC_SHARE; alter share ABC_share add accounts = dev_account; In the developer account:
use role accountadmin; create database ABC_DEV FROM share prod_account.ABC_SHARE; grant imported privileges on database ABC_DEV to role developers; What is the reason the development team cannot see the data in the tables in the developer account?
Options
- AThe Data Engineer did not grant on the schema and on the tables in the
- BThe Data Engineer did not grant to the schemas and tables in the
- CThe Data Engineer did not grant select on the schema and tables in the share in the developer
- DThe Data Engineer did not grant on the database in the developer account.
How the community answered
(37 responses)- A81% (30)
- B5% (2)
- C11% (4)
- D3% (1)
Explanation
Option A is correct because Snowflake Data Sharing requires explicit privilege grants at every level of the object hierarchy within the share. The engineer granted USAGE on the database to the share, but never granted USAGE on the schemas or SELECT on the tables - without these, the share exposes an empty database that consumers can connect to but cannot read from.
Option B is wrong because the problem is not in the developer account setup - GRANT IMPORTED PRIVILEGES correctly delegates all shared object access to the developers role on the consumer side. The gap is in how the share was configured on the producer side.
Option C is wrong because it conflates privilege types: schemas require USAGE, not SELECT. SELECT applies only to tables (and views). A share granting SELECT on a schema would be invalid syntax.
Option D is wrong because the engineer did grant on the database in the developer account (grant imported privileges on database ABC_DEV to role developers), so this step was completed correctly.
Memory tip: Think of Snowflake sharing as a 3-key lockbox - Database, Schema, Table. You must hand over all three keys in the share (USAGE on database, USAGE on schema, SELECT on tables), or the consumer gets the box but can't open what's inside.
Topics
Community Discussion
No community discussion yet for this question.