SnowPro Advanced: Security Engineer Question 257
Single answerManage interfaces for auditorsAn external audit firm needs read-only access for two weeks to review object definitions, role grants, and recent login/query activity in your Snowflake account. The auditors must not be able to see sensitive table data, create objects, or use client tools other than the Snowsight web interface. Your company also wants to minimize operational overhead and avoid exposing the classic web interface or SQL worksheets in external BI tools. Which approach best meets these requirements?
- A
Create a dedicated auditor user and role with imported privileges on the SNOWFLAKE database as needed for metadata and usage views, grant only the minimum account-level monitor privileges required, assign a small warehouse for any queries they must run, and configure a network policy and authentication policy so the auditors can access only through approved locations and the Snowsight interface.
- B
Grant the auditors the ACCOUNTADMIN role temporarily, but restrict their access by telling them to use only Snowsight dashboards and trust that object ownership rules will prevent changes to production objects.
- C
Create a secure share containing ACCOUNT_USAGE views and grant the auditors access through reader accounts, because reader accounts can query all account metadata without needing a Snowflake user or role in your account.
- D
Provision the auditors with SYSADMIN, deny SELECT on all business schemas, and rely on the fact that SYSADMIN cannot view account usage or security metadata unless SECURITYADMIN is also granted.
Show answer and explanation
Correct answer: A
Explanation
For auditors, Snowflake best practice is to provide a dedicated, time-bounded user/role with only the privileges required for the audit scope, typically focused on metadata, grants, and usage history rather than underlying business data. In practice, this usually means granting access to the SNOWFLAKE database interfaces that expose account usage and governance metadata, plus only the minimum account-level privileges needed to inspect the environment. If the user needs to execute queries, a warehouse is required, but it should be isolated and sized minimally. Interface management matters here: Snowsight can be the approved access path for auditors because it offers a controlled browser-based interface, while network policies and authentication/session policies help restrict how and from where they connect. High-privilege roles such as ACCOUNTADMIN or SYSADMIN are inappropriate for auditors because they allow actions well beyond observation. Likewise, secure shares and reader accounts are not the correct mechanism for exposing internal account audit metadata. This aligns with Snowflake guidance around least privilege, role-based access control, SNOWFLAKE database metadata access, network policies, and governed user access through Snowsight.
- A. Correct.
Correct. This follows least-privilege design and matches how auditors are typically onboarded in Snowflake. Auditors often need access to metadata and monitoring information rather than business data. Access to SNOWFLAKE database views, including relevant ACCOUNT_USAGE and other metadata interfaces, should be granted only as required, along with narrowly scoped monitoring privileges. If they must run queries, they need a warehouse, but it can be small and dedicated. Network policies can restrict where they connect from, and authentication/session controls can further constrain access. Using Snowsight as the approved interface is appropriate for auditor workflows because it provides a governed web UI without requiring external client tooling.
- B. Incorrect.
Incorrect. ACCOUNTADMIN is far too broad for external auditors and violates least privilege. ACCOUNTADMIN can manage security, billing-related settings, integrations, objects, and far more than is required. Snowsight does not inherently prevent users with powerful roles from making changes. Trusting process guidance instead of enforcing controls through roles and policies is not an acceptable security design.
- C. Incorrect.
Incorrect. Secure sharing and reader accounts are used to share database objects such as tables and secure views, not to expose your account's internal security and usage metadata for auditing of your Snowflake account. ACCOUNT_USAGE and many governance-related interfaces are accessed within the account through roles and privileges, not by packaging them into a share for an external reader account in the way described here.
- D. Incorrect.
Incorrect. SYSADMIN still has broad object-management capabilities and is not appropriate for a restricted external auditor persona. Denying SELECT on business schemas does not adequately limit the role, because SYSADMIN can create and manage many objects and can inherit broad administrative access depending on role hierarchy. Also, the statement about SYSADMIN being safe because it cannot view account usage or security metadata is a misconception; the issue is not only metadata visibility but excessive administrative capability overall.