You have a Snowflake database named 'SALES DB' containing schemas 'RAW' and 'TRANSFORMED'. The 'RAW' schema holds raw data ingested from various sources, and the 'TRANSFORMED' schema contains cleansed

Question

Options

• AGRANT SELECT ON ALL TABLES IN SCHEMA SALES DB.TRANSFORMED TO ROLE DATA
• BGRANT USAGE ON DATABASE SALES DB TO ROLE DATA ANALYST; GRANT SELECT ON
• CGRANT USAGE ON DATABASE SALES DB TO ROLE DATA ANALYST; GRANT USAGE ON
• DGRANT ALL PRIVILEGES ON SCHEMA SALES DB.TRANSFORMED TO ROLE DATA
• EGRANT SELECT ON SCHEMA SALES DB.TRANSFORMED TO ROLE DATA ANALYST;

• A
  26% (10)
• B
  18% (7)
• C
  44% (17)
• D
  10% (4)
• E
  3% (1)

Explanation

Option C is correct because Snowflake requires a complete privilege chain: USAGE on the database to enter it, USAGE on the schema to navigate within it, and SELECT on the tables to read them - omitting any link in this chain breaks access entirely, and using only SELECT grants read-only access, satisfying the security requirement.

Why the distractors fail:

• A - Grants SELECT on tables but skips USAGE on both the database and schema; the role cannot even navigate to the tables.
• B - Grants USAGE on the database and SELECT on tables but omits USAGE on the schema, breaking the access chain at the schema level.
• D - GRANT ALL PRIVILEGES is overly permissive; it includes INSERT, UPDATE, DELETE, and other modification rights, violating the least-privilege requirement.
• E - GRANT SELECT ON SCHEMA is not valid syntax for table access in Snowflake; you cannot grant SELECT at the schema level to propagate it to tables - privileges must be granted on the objects themselves.

Memory tip: Think of Snowflake access as a nested door lock - Database → Schema → Table. You need a key (USAGE) for each door before you can read (SELECT) what's inside the last room. ALL PRIVILEGES hands over the master key, which is never the "secure" answer.

No community discussion yet for this question.