Account access and security: free practice questions

UNDROP requires the same privileges as CREATE on the parent object. Since SYSADMIN owns the schema, SYSADMIN (or any role that inherits SYSADMIN, such as ACCOUNTADMIN) can execute UNDROP SCHEMA. Option A is wrong because USAGE on a database does not grant the ability to undrop child schemas. Option B is wrong because ACCOUNTADMIN can do it, but it is not the *only* role — SYSADMIN can as well, so 'only ACCOUNTADMIN' is incorrect. Option C is wrong because ownership of the database is not the key privilege; ownership of or CREATE privilege on the schema's parent is what matters, and inheriting SYSADMIN (not just owning the database) is the relevant path.

CURRENT_USER() returns the name of the authenticated user — 'ALICE' — regardless of which roles are active. Therefore the policy filters rows to those where REGION = 'ALICE'. Option A is wrong because row access policies do not union results across roles; the policy expression runs once per query using session context functions. Option B is wrong because row access policies apply to all users including those with managerial roles unless the policy expression explicitly exempts them. Option D is wrong because the policy as written uses CURRENT_USER(), not CURRENT_ROLE(); if the policy used CURRENT_ROLE() the answer would differ, but that is not what this policy does.

Option A is correct: Snowflake's privilege model allows separating the CREATE MASKING POLICY privilege (needed to define policies) from the APPLY MASKING POLICY privilege (needed to attach policies to columns). By assigning these to distinct roles held by distinct users, you enforce separation of duties natively within Snowflake. Option D is correct and is a more granular version of the same principle — creating separate roles with CREATE vs. APPLY privileges and assigning them to different personnel is the recommended Snowflake pattern for this compliance control. Option B is incorrect; SECURITYADMIN and SYSADMIN are powerful system roles that can both create AND apply policies, so assigning them to different users does not cleanly separate these specific duties and introduces other privilege concerns. Option C is incorrect; using an external ticketing system is a compensating control but does not enforce the separation at the Snowflake platform level — a user with both privileges could still bypass it. Option E is incorrect; there is no MASKING_POLICY_SEPARATION account parameter in Snowflake — this is a fabricated setting. Option F is incorrect; revoking SYSADMIN ownership and auditing via ACCOUNT_USAGE is a detective control, not a preventive one, and does not enforce the separation.

ACCOUNTADMIN sits at the top of the system role hierarchy and inherits all privileges from SYSADMIN and SECURITYADMIN, making option B correct. Snowflake recommends having at least two users assigned to ACCOUNTADMIN for emergency access purposes, making option E correct. Option A is wrong because system roles are created by Snowflake at account provisioning — ACCOUNTADMIN cannot create other system roles. Option C is wrong because best practice is to grant ACCOUNTADMIN sparingly and to use SYSADMIN for database creation. Option D is partially true in principle but is a distractor — it is SECURITYADMIN and ACCOUNTADMIN that manage governance, and the SNOWFLAKE database usage views are accessible to ACCOUNTADMIN, but this option is not among the two most accurate and distinguishing facts listed.

The 'session:role:<role_name>' OAuth scope tells Snowflake to establish the session with the specified role as the primary role. It does not permanently grant the role — it only scopes the token's session. Option A is wrong because OAuth scopes are session-scoped, not permanent role assignments. Option C is partially correct in that a user can use inherited privileges, but the scope itself restricts the *primary* role to DATA_SCIENTIST_ROLE rather than allowing unrestricted role switching. Option D is wrong because OAuth scopes have nothing to do with MFA bypass — MFA and OAuth are separate authentication mechanisms.