> The most confusing part of terraform for me is that terraform's view of the infrastructure is a singleton config file that is often stored in that very infrastructure.

These folks also have an article about that: https://newsletter.masterpoint.io/p/how-to-bootstrap-your-st...

There are three things:

* Your terraform code

* The state terraform holds which is what it thinks your infrastructure state is

* The actual state of your infrastructure

>Why don't cloud providers have a nice way for tools like TF to query the current state of the infra?

What a terraform provider is is code that queries the targeted resources through whatever APIs they provide. I guess you could argue these APIs could be better, faster, or more tuned towards infrastructure management... but gathering state from whatever resources it manages is one of the core things terraform does. I'm not sure what you're asking for.

At $WORK we have a Git repo set up by the devops team, where we can manage our junk by creating Terraform resources in our main AWS account.

The state however is always stored in a _separate AWS account_ that only the devops team can manage. I find this to be a reasonable way of working with TF. I agree that it is confusing though, because one is using $PROVIDER to both create things and manage those things at the same time, but conceptually from TF’s perspective they are very different things.

> Why don't cloud providers have a nice way for tools like TF to query the current state of the infra? Maybe they do and I'm doing IaC wrong?

This is technically how Ansible works. Here's an extensive list of modules that deploy resources in various public clouds: https://docs.ansible.com/projects/ansible/2.9/modules/list_o...

That said, it looks like Ansible has deprecated those modules, and that seems fair - I haven't actually heard of anyone deploying infrastructure in a public cloud with Ansible in years. It found its niche is image generation and systems management. Almost all modern tools like Terraform, Pulumi, and even CloudFormation (albeit under the hood) keep a state file.

> Why don't cloud providers have a nice way for tools like TF to query the current state of the infra?

They do! In fact, this is my greatest pet peeve with TF, it adds state when it's not needed.

I was doing infra-as-code without TF with AWS long time ago. It went like this:

  env_tag = "${project_name}-${env_name}"  
  aws_instances = conn.describe_instances(filter_by_tag={"env_tag": env_tag})
  if len(aws_instances) != 1:
    conn.launch_aws_instances(tags={"env_tag": env_tag})

AWS has tag-on-create now, making this sort of code reliable. Before that, you could do the same with instance idempotency tokens. GCP also has tags.

There is the code, the recorded state of the infra when you applied the code and the actual state at some point in the future (which may have drifted) . You store the code in git, the recorded state (which contains unique IDs, ARNs etc) in a bucket and you read the "actual state" next time you run a plan, and you detect drift.

These days people store the state in terraform cloud or spaceliftor env0 or whatever. Doesn't have to be the same infra you deployed.

If you were a lunatic you could not use a state backend and just let it create state files in the terraform code directory, check the file into git with all those secrets and unique ids etc.

I assumed it was going to be about tensorflow