CREATE). "Safe" queries usually do not require code review.
DROP). "Unsafe queries" usually do require more attention from reviewers.
--apply-replace-tableis a safety check to prevent overspending of credits. Unlike
CREATE OR REPLACE TABLE ... AS SELECTrequires an active warehouse and full rewrite of original table, which may cost a lot if table is big.
--apply-account-paramsis a safety check to prevent accidental changes in ACCOUNT PARAMETERS. It may cause security issues if applied to account-level NETWORK POLICY without review. It may cause timeouts during query execution, it may break timestamp-related settings, etc. etc.
--apply-network-policyis a safety check to prevent changes in NETWORK POLICIES. Unlike "on premise" DWH systems, Snowflake is exposed to anyone on the Internet, and the only thing preventing a free access is NETWORK POLICY. Updates to NETWORK POLICY should not be applied without review.
--apply-resource-monitoris a safety check to prevent changes in RESOURCE MONITORS. It may cause all sorts of issues from overspending to inability of business users to run even a single query due to resource monitors running out of credits quota.
--apply-row-access-policyis a safety check for data security "policies". The main issue with policies is related to lack of transactional DDL in Snowflake. Currently it is not possible to re-create the whole policy "atomically". First all references must be dropped, after that policy can be re-created, and all refs should be re-applied once again. But during all these operations your data remains potentially exposed. All changes to policies should be applied under the strict control.
STDOUTand are available for copy-paste and manual review by administrator.
ACCOUNTADMINrole. All "suggested" queries use fully-qualified identifiers, and the "OWNERSHIP" of schema-level object will remain intact due to FUTURE GRANTS.