COF-C03 Question 348
Single answerPublicA data engineering team stores reusable file formats and stages in the PUBLIC schema of a database so multiple teams can access them. During a security review, the Snowflake administrator is asked to reduce unnecessary access while still allowing analysts to use approved objects in that schema. Which action should the administrator take to align with Snowflake best practices for the PUBLIC schema?
- A
Revoke unnecessary privileges granted to the PUBLIC role and grant required privileges only to specific roles that need access
- B
Drop the PUBLIC schema because it is only intended for temporary objects and should not be used in production
- C
Rename the PUBLIC schema to a custom schema name so only authorized users can find it
- D
Grant OWNERSHIP on the PUBLIC schema to all analyst roles so they can manage access independently
Show answer and explanation
Correct answer: A
Explanation
This question tests understanding of the distinction between the PUBLIC schema and the PUBLIC role, a common exam topic and real-world source of confusion. In Snowflake, each database includes a PUBLIC schema by default, and the PUBLIC role is automatically granted to all users. Because of that inheritance, granting privileges to PUBLIC should be done cautiously. Snowflake security best practice is to use role-based access control and grant privileges to custom roles rather than relying on the PUBLIC role for anything beyond intentionally universal access. The safest and most maintainable approach in this scenario is to revoke unnecessary privileges from PUBLIC and grant only the needed privileges to specific analyst or engineering roles. This aligns with Snowflake documentation on access control and least-privilege design.
- A. Correct.
Correct. In Snowflake, the PUBLIC role is automatically granted to every user, so privileges granted to PUBLIC effectively become widely available. Best practice is to avoid broad grants to PUBLIC unless they are truly intended for all users, and instead grant access to specific custom roles. If objects such as stages or file formats in the PUBLIC schema should be used only by certain teams, the administrator should revoke overly broad privileges from PUBLIC and assign the minimum necessary privileges to designated roles.
- B. Incorrect.
Incorrect. The PUBLIC schema is a standard schema automatically created in databases and can be used in production. It is not limited to temporary objects. The issue in this scenario is not the existence of the schema, but overly broad access caused by grants to the PUBLIC role.
- C. Incorrect.
Incorrect. Renaming a schema does not provide security. Object discoverability is not the same as access control in Snowflake. Privileges are enforced through roles and grants, so changing the schema name would not reduce unauthorized access.
- D. Incorrect.
Incorrect. Granting OWNERSHIP broadly would significantly increase risk because OWNERSHIP is a powerful privilege that allows full control, including the ability to transfer ownership and manage grants. This violates least-privilege principles and is not an appropriate way to manage shared access.