A security auditor has identified that several users have been granted the role directly. Your company's security policy mandates that 'ACCOUNTADMIN' should only be used in emergency scenarios and acc

Question

Options

• ACreate a new custom role (e.g., 'ADMIN ROLE) and grant it the 'ACCOUNTADMIN' role. Then
• BCreate a new custom role (e.g., 'ADMIN ROLE) and grant it all the privileges currently held by the
• CRevoke the 'ACCOUNTADMIN' role from all users and inform them that they should not be using
• DCreate a new custom role (e.g., 'ADMIN_ROLE) and grant ` ACCOUNTADMIN' to this role. Then
• ECreate a new custom role (e.g., 'ADMIN ROLE') and grant it 'OWNERSHIP on the account. Grant

• A
  72% (23)
• B
  3% (1)
• C
  16% (5)
• E
  9% (3)

Explanation

Options A and D together implement the correct Snowflake security pattern: creating an intermediary custom role (e.g., ADMIN_ROLE) and granting ACCOUNTADMIN to it, then assigning users to this custom role instead of directly to ACCOUNTADMIN. This preserves the role hierarchy Snowflake recommends - users get ACCOUNTADMIN-level access through a subordinate role, enabling temporary grants and revocations without touching ACCOUNTADMIN directly, which minimizes workflow disruption.

Why the distractors are wrong:

• B attempts to replicate ACCOUNTADMIN's individual privileges onto a new role, which is fragile (misses future privileges, breaks the intended hierarchy, and is operationally complex to maintain).
• C simply revokes ACCOUNTADMIN from all users with no alternative access path - this violates the "minimize disruption" requirement and leaves users unable to perform their work.
• E granting OWNERSHIP ON ACCOUNT to the custom role is not a valid or recognized Snowflake security pattern; ownership is managed at the object level, not at the account level this way, and it doesn't align with the ACCOUNTADMIN subordinate-role requirement.

Memory tip: Think of it as building a "drawbridge" to ACCOUNTADMIN - you never let users walk directly onto the castle (direct role grant); instead they cross a custom bridge (subordinate role) that can be raised or lowered (granted/revoked temporarily) as needed.

No community discussion yet for this question.