There’s this idea floating around that Infrastructure as Code is “good practice” I don’t really agree.
For me, it’s a must. A non-negotiable. Especially once you’re dealing with platforms that touch sensitive data, internal tools, or real users. And if you’ve ever worked with Snowflake, you probably know what I mean.
A Snowflake setup with real-world chaos potential Imagine this: You’ve got a Snowflake account up and running. Teams are running dashboards. You have masked columns, role hierarchies, network policies, user provisioning. All the grown-up stuff. But then someone, somewhere, opens the UI, changes one little thing— Deletes a role, tweaks a grant, changes a warehouse size.
Maybe nobody notices right away. Maybe you find out days later when something silently breaks. By that point, your manual change is gone. There’s no rollback. And worst of all—you don’t even know who or why.
The Access Control repo: YAML over memory
That’s why I built a repo I simply called access-control. Nothing fancy. Just YAML files and some Terraform (or Tofu, if you prefer).
Each team gets defined once, like this:
team: marketing
roles:
- marketing_admin
- marketing_data
user: marketing_user
quota: 150
whitelist:
- 12.34.56.0/24
This simple declaration leads to the following:
- A Snowflake database for the team
- Two roles: one admin, one read-only
- A service user, connected only to the team
- A warehouse with quota limits
- Alerts for credit overuse
- Grants between all these components
- IP whitelisting via network policy
It’s not rocket science. But it’s complete. And most importantly, it’s repeatable.
Your life just got easier
By sticking to this model, you no longer have to:
- Look up which warehouse size you used last time
- Remember what kind of role grants were needed
- Click through the UI to piece things together
- Pray that the last person did everything correctly
You just expand your YAML Run the CI/CD pipeline Review the plan And apply the changes
Now everything has a state. You get visibility. And your platform starts to feel like something intentional, not accidental. But what if someone messes it up? It happens.
Here’s the difference when you do IaC:
If the mistake happens in the UI, the pipeline reverts it. If the mistake happens in the repo, Git has your back.
You get a full history of every change. You can ask: “What was the idea here?” instead of “Who broke it?”
It’s not about finger-pointing. It’s about transparency. Infrastructure as Code creates space for shared understanding, and in the best case, shared responsibility.
Final thoughts
Snowflake is powerful. But power without structure leads to chaos. When you define your platform in code, you get structure for free.
You don’t need to memorize how to create masking policies. You don’t need to rely on someone else’s bookmarks of Snowflake docs. You define it once. In YAML. With rules, alerts, roles, and policies. You run a pipeline. And you know exactly what you’re getting. Every time.
I can share the structure of my access-control repo, the CI/CD pipeline setup, or help you define your own team model for Snowflake.
It’s one of those things you only need to set up once—and you’ll wonder why you didn’t do it earlier.