FAST 0-org-setup: what’s the rationale for separate org state bucket vs stage state bucket?

[kovagoadam]

I’m looking at the default buckets layout:

• iac-org-state for org-level automation
• iac-stage-state for other stages (with per-stage prefixes + IAM via managed_folders)

Can someone share the intent behind using two buckets instead of a single bucket with prefixes for everything?
Things I’m trying to understand:

1. Is this primarily for IAM / blast-radius separation, or are there backend/locking/lifecycle/circular dependency reasons too?
2. Is “one bucket for all state” considered an anti-pattern in FAST, or just not the recommended default?
3. Are there scenarios where you’d strongly recommend keeping org state physically separate (different bucket / project)?

Happy to open an Issue/PR if there’s an enhancement needed—right now I mainly want to understand the design choice.

[ludoo]

Hey, thanks for asking. The current approach evolved organically from before GCS folders were available and we were forced to use one bucket per state file, to now so it's part part of a super-rational plan.

What we always enforced is IAM separation, which as you observe we now do via GCS folders. Leaving the org-setup state in its own bucket was mainly a way of expressing the criticality of this stage, and also giving users a practical example on how to use both approaches (separate buckets vs folders).

Here too I would go back to our fundamental goal, which is to maintain a toolkit that we expect users to customize and tune to specific requirements. So while we are pretty strict on high level security concerns (the IAM/blast radius segregation here), we tend to prefer providing explicit ways of implementing different patterns.

Sorry if this generates some confusion, maybe a note in the org setup README would help users wrap their heads around this better?

[kovagoadam]

Thanks for the clarification — that explanation helps a lot.

It’s good to understand that IAM/blast-radius separation is the real invariant, and that the org bucket split is partly historical and partly illustrative.

I agree that a short note in the org-setup README would likely make this clearer for others as well. I’m happy to open a small PR to add that context when I have some time.