2.3.2. State as the Source of Mapping

💡 First Principle: Every plan Terraform produces is computed relative to state — so two engineers running the identical configuration against different state files can get completely different plans, because the diff depends on what each state believes already exists.

When you first apply a configuration, Terraform creates real resources and records their IDs in state, binding each resource address (like aws_instance.web) to a concrete object. On the next run, Terraform reads state, refreshes those resources against their APIs, and diffs the result against your configuration. Because the plan is "config minus state," the same config can mean "create everything" against empty state or "no changes" against fully-populated state.

This also explains why state can contain sensitive data in plaintext — if a resource attribute is a password or key, its value is cached in state regardless of whether you marked it sensitive in configuration. Protecting state (encryption at rest, restricted access, remote backends) is therefore a security requirement, not just an operational one.

⚠️ Exam Trap: A classic true/false item: "Marking a value as sensitive keeps it out of the state file." This is false. The sensitive flag only hides values from CLI/plan output. The value still lives in state in plaintext. (Ephemeral values and write-only arguments, covered in Phase 4, are the features that actually avoid persisting secrets in state.)

Reflection Question: Using the "plan = config minus state" idea, explain why importing a resource into state changes future plans even though the configuration text didn't change.