> this is difficult for me to think about in the same way as trying to picture a 4th dimension.

Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.

tagging provider resources? not speaking for every provider or api, but at least on AWS not everything that can be managed supports tagging.

also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.

infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.

totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.

Querying the cloud provider apis for current state? Go to the actual source of truth?

I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?

Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file.

Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that.

Unless someone makes a common standard for resource reporting that all cloud providers implement.

The state file is more than a cache. If it was just a cache, it wouldn't be problematic.

exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.

you’d be subject to rate limits and all manner of potential issues and outages if you only query the providers api.

that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.