Author name: Abhay

Yesterday you learned how to control what people see inside a table — masking columns, filtering rows, tagging data, and scanning for PII. Today we’re zooming out to the infrastructure level: how Snowflake protects data at the encryption layer, and what happens when an entire region goes down. On Day 19, we introduced the basics […]

Yesterday you locked down where people can connect from and how data is encrypted underneath. Today we’re going one layer deeper: controlling what people see when they query data — even if they have full access to the table. Same table, same query, completely different results depending on who runs it. That’s dynamic data masking

Yesterday you learned how users prove who they are (authentication). Today we’re looking at the other side of the security coin: where they’re connecting from, and how the data itself is protected in transit and at rest. Your Snowflake account is accessible over the internet by default — anyone with valid credentials can connect from

Yesterday you learned who can do what (system roles, custom roles, hierarchy). Today we tackle how those users prove they are who they say they are. Snowflake supports five-plus authentication methods — passwords with MFA, federated SSO via SAML 2.0, Snowflake OAuth, external OAuth, and key-pair authentication. Snowflake is actively phasing out password-only logins entirely,

Yesterday you learned how Snowflake’s access control works — RBAC, DAC, GRANT, REVOKE, privilege inheritance. Today we’re looking at who holds the keys. Snowflake ships with six system-defined roles, each with a specific job in the hierarchy. Use the wrong one and you’re either locked out of your own objects or handing someone the master