nerdexam
Snowflake

SOL-C01 · Question #33

A Snowflake account has the following role hierarchy: - ACCOUNTADMIN - SECURITYADMIN - DB_ADMIN - ETL USER - REPORT USER SECURITYADMIN reports to ACCOUNTADMIN, DB_ADMIN reports to SECURITYADMIN, ETL_U

The correct answer is B. Grant the 'CREATE TEMPORARY TABLE' privilege directly to the "REPORT_USER role. E. Create a new custom role, 'TEMP TABLE CREATOR. Grant the 'CREATE TEMPORARY TABLE. Granting CREATE TEMPORARY TABLE directly to REPORT_USER (B) is the most straightforward least-privilege solution - john.doe already holds that role, so the privilege lands exactly where it's needed without touching any other role. Option E is equally valid as a best practice: cre

Snowflake Account and Security

Question

A Snowflake account has the following role hierarchy: - ACCOUNTADMIN - SECURITYADMIN - DB_ADMIN - ETL USER - REPORT USER SECURITYADMIN reports to ACCOUNTADMIN, DB_ADMIN reports to SECURITYADMIN, ETL_USER and REPORT USER reports to DB_ADMIN. A user 'john.doe' has been granted the `REPORT USER role. 'john.doe' needs to execute a query that requires temporary table creation. However, the execution fails. Which of the following steps would CORRECTLY grant the minimum necessary privilege to 'john.doe' such that he can create temporary tables without compromising security or overly broad access? Select all that apply:

Options

  • AGrant the 'CREATE TEMPORARY TABLE' privilege on the database to the 'DB_ADMIN' role.
  • BGrant the 'CREATE TEMPORARY TABLE' privilege directly to the "REPORT_USER role.
  • CCreate a new custom role, Grant the 'CREATE TEMPORARY TABLE privilege on the database to
  • DGrant the ACCOUNTADMIN role to the User john.doe
  • ECreate a new custom role, 'TEMP TABLE CREATOR. Grant the 'CREATE TEMPORARY TABLE

How the community answered

(30 responses)
  • A
    27% (8)
  • B
    50% (15)
  • C
    17% (5)
  • D
    7% (2)

Explanation

Granting CREATE TEMPORARY TABLE directly to REPORT_USER (B) is the most straightforward least-privilege solution - john.doe already holds that role, so the privilege lands exactly where it's needed without touching any other role. Option E is equally valid as a best practice: creating a dedicated TEMP_TABLE_CREATOR role isolates the privilege, making it auditable and easily revocable across multiple users without altering the core role hierarchy.

Why the distractors fail:

  • A is wrong because in Snowflake, privileges flow upward through the hierarchy - granting to DB_ADMIN gives that privilege to DB_ADMIN and its parents (SECURITYADMIN, ACCOUNTADMIN), but REPORT_USER (a child role) does not inherit downward. John.doe still can't create temp tables, and the privilege is overly broad.
  • C appears to grant the privilege on the database object to a new role but is cut off - if it lacks the step of granting that new role to REPORT_USER or john.doe, it's incomplete and ineffective.
  • D grants ACCOUNTADMIN - the most powerful role in the account - to a single user for a single table operation, which is a severe security violation and directly contradicts least-privilege principles.

Memory tip: Think "privileges climb up, not trickle down" for Snowflake role hierarchies. To give a user a new privilege, target their current role or a new child role assigned to them - never a parent role you assume will cascade down.

Topics

#RBAC#Role hierarchy#Privilege grants#Temporary tables

Community Discussion

No community discussion yet for this question.

Full SOL-C01 Practice