Terraform Core Vocabulary Exercises

1 / 5

A developer runs terraform plan and sees the output:

Plan: 3 to add, 1 to change, 0 to destroy.

What does this output communicate to the team?

terraform plan previews changes without making them. The summary line uses three counters:

Counter	Meaning	Symbol in plan output
to add	New resources to be created	`+`
to change	Existing resources to be modified in-place	`~`
to destroy	Resources to be deleted	`-`

no-op — a resource Terraform checked but found no changes needed
in-place update — modification without destroying the resource (e.g. changing a tag)
destroy and recreate (replacement) — some attribute changes force the resource to be deleted and recreated (e.g. changing an EC2 AMI ID)

Understanding plan output is essential for IaC code reviews — reviewers should always check for unexpected destroys before approving.

2 / 5

A team member says: "The Terraform state file contains a complete record of the infrastructure."

What does the Terraform state file actually represent?

Terraform state (.tfstate) is Terraform's model of reality. It stores: resource IDs, attribute values captured at last apply, and inter-resource dependencies.

Concept	Explanation
state refresh	Terraform queries the real cloud API to update the state file with current resource attributes
state drift	When real infrastructure diverges from what the state file records (e.g. manual console changes)
remote state	State stored in S3, GCS, or Terraform Cloud rather than a local file — required for team collaboration
state lock	Prevents two concurrent applies from corrupting the state file simultaneously

Security note: Never commit state to Git — it may contain secrets (database passwords, private keys) in plaintext.

3 / 5

A DevOps engineer says: "I ran terraform import on the existing RDS instance."

What does terraform import do?

terraform import tells Terraform about a resource that was created manually or by another tool. The workflow:

Write the corresponding resource block in your .tf configuration
Run terraform import <resource_address> <cloud_resource_id>
Run terraform plan to verify the configuration matches the real resource (zero diff)

Term	Meaning
bringing resources under management	The process of making Terraform responsible for a pre-existing resource
resource address	The Terraform identifier: `aws_db_instance.main`
generated configuration	In TF 1.5+, `terraform plan -generate-config-out=generated.tf` writes the .tf block for you

4 / 5

A pull request description says: "This adds a lifecycle { prevent_destroy = true } block to the production database resource."

What does this configuration enforce?

prevent_destroy = true causes Terraform to return an error if any plan operation would destroy this resource, even if destruction is triggered by another change (e.g. replacing a module).

lifecycle meta-argument	Effect
`prevent_destroy = true`	Error on any plan that would destroy this resource
`create_before_destroy = true`	Create the replacement before destroying the old resource (zero-downtime replacement)
`ignore_changes = [attribute]`	Ignore drift for specified attributes (e.g. tags managed outside Terraform)
`replace_triggered_by`	Force replacement of this resource when another resource changes

Typical candidates for prevent_destroy: production RDS instances, S3 state buckets, KMS keys, VPCs.

5 / 5

A DevOps engineer says: "We use Terraform workspaces to manage dev, staging, and prod environments from a single configuration."

What is a Terraform workspace?

A Terraform workspace is a named state slice within the same backend. terraform workspace new staging creates a separate state file for staging while using the same .tf configuration.

Approach	Isolation level	Best for
Workspaces	Separate state, shared backend and code	Lightweight environment variants with near-identical configs
Separate state backends	Fully isolated state and backend	Production environments requiring strict blast-radius isolation
Separate directories	Isolated code, state, and backend	Environments with significant configuration differences

Best practice: For production, use separate state backends and/or directories. Workspaces are suitable for dev/test variants — not as a substitute for proper environment isolation.