ARA-C01 Question 2
Single answerDomain 1.0: Account and Security (25%)A global company is designing access controls for its Snowflake environment. The security team wants to ensure that application service accounts used by ETL tools can load data into specific schemas but cannot create users, modify network policies, or grant privileges to other roles. At the same time, the company wants to simplify long-term administration by separating user and role management from object privilege management. Which approach best meets these requirements?
- A
Grant the ACCOUNTADMIN role to the ETL service accounts, then restrict object access through future grants on the target schemas.
- B
Use a single custom role for both user administration and schema object privileges, and grant that role to the ETL service accounts.
- C
Create custom functional roles for data loading privileges on the required schemas, and keep user/role administration in separate roles managed by a higher-level administrative role.
- D
Grant SECURITYADMIN to the ETL service accounts so they can inherit only the privileges required for loading data through role hierarchy.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to separate functional data-access roles from administrative roles. In Snowflake, a common best practice is to design access using custom roles aligned to business or technical functions, then grant only the minimum privileges required. ETL service accounts typically need limited object privileges such as USAGE on warehouses, databases, and schemas, plus privileges needed to load data into specific objects. They should not receive powerful system roles like ACCOUNTADMIN or SECURITYADMIN.
This scenario also highlights separation of duties. Snowflake administrative responsibilities are commonly split so that security administration (for example, user and role management) is kept distinct from object-level access design and operational data access. This reduces the blast radius of credential compromise and simplifies auditing and governance. These practices are consistent with Snowflake guidance around role-based access control, least privilege, and minimizing use of high-level system roles except for a small number of trusted administrators.
- A. Incorrect.
Incorrect. ACCOUNTADMIN is the most powerful system role in a Snowflake account and is not appropriate for ETL service accounts that only need limited data-loading access. Even if schema-level privileges are configured, ACCOUNTADMIN retains broad administrative capabilities, including actions far beyond the stated requirements. This violates least-privilege design and increases operational and security risk.
- B. Incorrect.
Incorrect. Combining user/role administration with object privilege management in a single custom role works against separation of duties and makes long-term administration harder, not simpler. Snowflake best practice is to separate access control responsibilities, typically distinguishing who manages users and roles from who manages object privileges. Giving ETL service accounts such a combined role would also exceed their required scope.
- C. Correct.
Correct. This approach aligns with least privilege and role-based access control best practices in Snowflake. ETL service accounts should receive narrowly scoped custom roles that allow only the required privileges for loading data, such as USAGE on database/schema and appropriate table or stage privileges. Separately, user and role administration should be handled through dedicated administrative roles rather than bundled with data access roles. This separation improves governance, reduces risk, and supports scalable administration.
- D. Incorrect.
Incorrect. SECURITYADMIN is intended for managing grants and security-related configuration, not for service accounts performing ETL loads. Granting SECURITYADMIN would allow the service accounts to manage roles and privileges, which directly conflicts with the requirement that they must not grant privileges to other roles. Role hierarchy does not make this safe if the parent role itself contains excessive authority.