SnowPro Associate: Platform Question 154
Single answer○ Use the PUBLIC SCHEMAA data engineering team creates a new database named ANALYTICS for a reporting project. Soon after, developers begin creating ad hoc tables in ANALYTICS.PUBLIC, while the BI team also starts storing shared views there. The Snowflake administrator wants to reduce accidental object creation in the default schema while still allowing teams to use the database. Which action best addresses this requirement?
- A
Revoke CREATE privileges on the PUBLIC schema from roles that should not create objects there, and direct users to create objects in purpose-built schemas instead.
- B
Drop the PUBLIC schema, because every new database can function normally without it.
- C
Rename the PUBLIC schema to REPORTING so users stop treating it as a default location.
- D
Disable the PUBLIC schema at the account level so new databases are created without it.
Show answer and explanation
Correct answer: A
Explanation
In Snowflake, each new database includes a PUBLIC schema by default. While it is available for use, relying on PUBLIC for mixed workloads often leads to poor governance, accidental object creation, and unclear ownership. The best practice is to create purpose-specific schemas and grant privileges intentionally. To reduce unwanted use of PUBLIC, administrators should revoke or limit CREATE privileges on that schema for non-admin roles while still allowing appropriate USAGE where needed. This follows Snowflake's access control model and schema-based organization guidance. The key exam concept is that PUBLIC exists by default and is managed through privileges, not by an account-level setting that removes or disables it.
- A. Correct.
Correct. In Snowflake, a database automatically includes a PUBLIC schema, and it is commonly used as a default location if teams are not given clearer schema-level boundaries. The practical way to prevent unwanted object creation is to control privileges on that schema, especially CREATE privileges, and guide users toward dedicated schemas such as STAGING, MART, or SEMANTIC. This aligns with least-privilege administration and better object organization.
- B. Incorrect.
Incorrect. PUBLIC is a default schema created with each database, and the premise that the database should simply function normally after dropping it is not the best answer for this scenario. The requirement is to reduce accidental object creation in the default schema, not to remove the schema entirely. Operationally, privilege management and use of dedicated schemas is the appropriate control.
- C. Incorrect.
Incorrect. Renaming the schema is not the standard or best control for preventing accidental object creation. The core issue is permissions and governance, not the schema name. Users with CREATE privileges could still create objects in the renamed schema.
- D. Incorrect.
Incorrect. There is no account-level feature to disable creation of the PUBLIC schema for new databases. PUBLIC is created by default when a database is created. The administrator must manage access and usage through grants and schema design.