A data engineer needs to grant a business analyst role ('BI ANALYST) the ability to query data in a specific schema ('SALES DATA) within a database ('REPORTING DB'). The business analyst should also b

Question

Options

• AGRANT USAGE ON DATABASE REPORTING DB TO ROLE BI ANALYST; GRANT SELECT ON
• BGRANT USAGE ON DATABASE REPORTING DB TO ROLE BI ANALYST; GRANT SELECT ON
• CGRANT ALL ON DATABASE REPORTING DB TO ROLE BI ANALYST; GRANT SELECT ON ALL
• DGRANT USAGE ON DATABASE REPORTING DB TO ROLE BI ANALYST; GRANT USAGE ON
• EGRANT USAGE ON DATABASE REPORTING DB TO ROLE BI ANALYST; GRANT SELECT ON

• A
  10% (3)
• B
  7% (2)
• C
  3% (1)
• D
  57% (17)
• E
  23% (7)

Explanation

Option D correctly follows the principle of least privilege by granting USAGE on the database and schema (which provides navigation access without modification rights), SELECT on tables in SALES_DATA (read-only query access), and CREATE TEMPORARY TABLE on the schema - covering exactly what the analyst needs, nothing more.

Why the distractors fail:

• A & B likely omit USAGE ON SCHEMA, which Snowflake requires as a prerequisite before any schema-level privileges take effect - without it, the role cannot even see the schema's objects.
• C uses GRANT ALL, which is the clearest violation: it hands over destructive privileges like INSERT, UPDATE, DELETE, and DROP, directly contradicting the "should not modify underlying tables" requirement.
• E likely grants SELECT but omits CREATE TEMPORARY TABLE, leaving the analyst unable to build the temporary working tables the question explicitly requires.

Memory tip: Think of Snowflake privileges as a locked filing cabinet - USAGE on database is the building key, USAGE on schema is the room key, and SELECT/CREATE TEMPORARY TABLE are the specific things you're allowed to do once inside. You need all three layers or the role hits a wall, and you should never hand over the master key (ALL) when a specific key will do.

No community discussion yet for this question.