Terraform / Language, providers, and managed identity / Lesson 1

Configuration, objects, and managed state

Separate desired configuration, resource identity, provider behavior, state, and remote reality before interpreting a Terraform workflow.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain declarative intent without assuming text order controls execution.
Distinguish configuration, plan, state, and real object ownership.

Describe intent rather than a sequence of commands

Terraform configurations describe objects and relationships that a chosen set of providers can manage. They do not simply execute each resource block from top to bottom. Terraform builds dependency information, compares available observations with desired configuration, and proposes actions. A provider supplies resource schemas and interactions with its target system. The same language can therefore describe very different systems, but shared syntax does not imply identical update, replacement, authentication, or deletion behavior across providers. Read the resource-specific contract before relying on a change.

Use a synthetic catalogue instead of cloud credentials

The course uses atlas-lab, a fictional service catalogue. Most configurations use the built-in terraform_data resource to discuss values and identities without requiring a cloud provider. Applying even that resource would still create or change Terraform state, so no initialization, planning, application, import, or state command is executed here. The following complete root-module example is editorial material targeting Terraform 1.16.x; it does not claim a running workspace or an already created object.

hcl A complete synthetic root module

terraform {
  required_version = ">= 1.16.0, < 1.17.0"
}

resource "terraform_data" "catalog" {
  input = {
    service  = "atlas-api"
    replicas = 2
  }
}

output "declared_service" {
  value = terraform_data.catalog.input.service
}

The address terraform_data.catalog names a configuration instance; it is not a cloud object id. The declared input contains atlas-api and replica count 2. The built-in provider needs no external required_providers entry, but execution would still involve Terraform workspace and state behavior. This example is not applied.

State records bindings and observed attributes

State connects Terraform resource addresses with managed object identities and stored attributes. It is not the source configuration, a universal inventory of everything in an account, or a guaranteed current view of remote reality. An object changed elsewhere can differ from its stored representation. Losing or selecting the wrong state can make an existing object appear unmanaged. Treat state selection and protection as part of the ownership model, not as a disposable cache that can be deleted to solve an unfamiliar error.

A comparison model is not a Terraform plan

The offline example compares a desired replica count with a stored teaching value. It demonstrates why a difference deserves review, not which action a real provider would choose. A provider might support an in-place update, require replacement, or reject the argument. A true plan can also contain unknown values, dependency effects, and refreshed observations. Label a simplified model clearly so its neat output is not mistaken for evidence of a safe infrastructure operation.

python Compare two in-memory catalogue records

desired = {'service': 'atlas-api', 'replicas': 2}
stored = {'service': 'atlas-api', 'replicas': 1}
changed = sorted(k for k in desired if desired[k] != stored.get(k))
print('changed_fields=' + ','.join(changed))

Expected output

changed_fields=replicas

Only replicas differs, so the output identifies that field. No provider, state file, backend, account, or Terraform command is consulted. The model deliberately avoids claiming whether that difference is an update or replacement.

Review ownership before operational transitions

A responsible workflow identifies the configuration revision, Terraform version, provider selections, input values, backend, and execution identity before considering a plan. It then reviews proposed changes, obtains the required authorization, and verifies actual outcomes. Those stages are conceptually separate even when automation combines them. A successful parser, a displayed plan, and a completed application are different claims. This theory course develops the reasoning for those boundaries; it does not grant authority to manage existing infrastructure or use configured credentials.

Common errors and fixes

Text order is treated as execution order.

Why it happens: Resource placement was mistaken for the dependency graph Terraform constructs.
How to fix it: Express real references and review dependencies rather than rearranging blocks to force order.
Prevent it next time: Describe value dependencies explicitly and avoid unnecessary ordering constraints.

An existing object appears absent.

Why it happens: The wrong state, workspace, backend, address, or execution context may be selected.
How to fix it: Establish the intended ownership context before proposing creation or import.
Prevent it next time: Record state identity and object ownership in reviewed project documentation.

A simple difference is declared safe to apply.

Why it happens: The provider action and downstream dependency effects were not examined.
How to fix it: Review the actual resource semantics and complete proposed change set.
Prevent it next time: Separate arithmetic demonstrations from infrastructure execution evidence.

Check your understanding

1. Does the HCL example create two cloud servers?

Show worked solution

No. It declares an input field named replicas in a built-in data-carrying resource. A label does not acquire cloud semantics automatically. Even applying this configuration would manage Terraform state rather than provision servers; no application is performed in the lesson.

2. Why should state not be deleted when an unfamiliar difference appears?