Does terraform contain sufficient information in statefile to track changes to config?

Does the terraform statefile contain the state of input from the last run?

Specifically, I’m trying to determine if terraform has sufficient information to:

1. Calculate the graph based on changed files (I know it does this)
2. Compare the input (not the cloud target state) to the last run and determine which resources input has changed

I know it can run a plan and use the statefile and current cloud state to see which resources should be changed.

I’m looking for something at an earlier stage, which wouldn’t even require connecting to the cloud.

It’s a diff between config input last time it was run and this time.

I think the closest example I could give is how kubernetes, when applying a resource, saves the last applied manifest on an annotation, so you can run a diff independent of the state of the cloud.

Short answer, yes.

The statefile tracks all config you have done in Terraform. Whether the input is from tfvars, environment variables, cmd arguments or console input does not matter. All config is tracked and any change will trigger a modify.

You can make terraform ignore changes by using lifecycle management.

And what you are asking about the "earlier stage", yes. That's what terraform plan is doing. You seem to misunderstand the workings of Plan. terraform plan check your current config against the statefile. Terraform actually never checks what exists in the environment before runtime. On runtime it will notice it exists if the provider throws an "Resource exists" error on attempt to create and you'll get a message telling you to import the resource into the state.

The connecting to the cloud part, if your backend statefile is not stored safely in a remote state, then you don't need to connect to the cloud. But i highly recomend setting up some cloud storage with backup and soft delete to safely store your statefile.

While planning Terraform considers several different pieces of information:

• Previous run state: this is the state snapshot that was written at the end of your most recent terraform apply, capturing the state reported by all of those providers immediately after they performed whatever actions they took during that apply.
• Current state: Terraform sends the previous run state for each resource instance to the provider and the provider returns an updated object after checking the real remote system. (Terraform describes this operation in its UI as "Refreshing".)
• Desired state: Terraform evaluates the expressions in your configuration to produce the desired state, which Terraform assumes is a description of the settings you would like the remote system to have.

Between these three artifacts Terraform can produce two kinds of information:

• Changes already made outside of Terraform: if "current state" is different from "previous run state" then that suggests that something changed outside of Terraform since the last operation. Terraform doesn't always display these in the UI, but it will do so if they seem related to changes from the next item.
• Proposed changes: If "desired state" is different from "current state" then that suggests you want to change something in the remote system, and so Terraform (actually: a Terraform provider) proposes an action that should change the remote system so that the current state matches the desired state, and those actions are what appear in as the description of the plan.

If you choose to apply a plan then the actions taken in the plan will each produce a "final state", which Terraform saves so it can become the "previous run state" for the next time you create a plan.

Terraform does not strictly track the configuration itself between runs, but since the final state is derived from the desired state and the desired state is derived from the configuration it does indirectly retain some information about what was in the configuration between runs, indirectly.

However, Terraform does not offer any way to just compare the previous run state with the desired state. All actions against a resource instance state are really performed by a provider rather than by Terraform itself, and providers must be initialized before they can perform those operations and most providers expect to be able to connect to the remote system during their initialization.

If you use terraform plan -refresh=false then you would disable the step of calculating the "current state" -- Terraform will just use an exact copy of the previous run state as the current state -- but the process of comparing the desired state with the current state to decide if any actions is required is implemented by providers as an online operation, where the provider typically expects to be able to access the remote system.