🏔️ Reading Terraform Error Output

State locking prevents two applies from writing to the same state file at once — this is a safety mechanism, not a crash.

Terraform state (terraform.tfstate) is the single source of truth mapping your configuration to real infrastructure. If two terraform apply runs happened simultaneously against the same state, they could corrupt it or apply conflicting changes. To prevent this, Terraform acquires a lock (often backed by a DynamoDB table when using an S3 remote backend) before making changes.

The Lock Info block tells you exactly who is holding the lock right now: Who: ci@runner-3421 means a CI pipeline run currently has it — most likely another pipeline run is still in progress, or a previous run crashed without releasing the lock.

What NOT to do: don't reach for -lock=false as a first response — that disables the safety check entirely and risks real state corruption if the other process is genuinely still running.

The correct approach: wait for the other run to finish, or if it's confirmed stuck/dead, use terraform force-unlock <LOCK_ID> with the ID shown (here 4f9b2e1a-...) after confirming with the team that no other apply is actually in progress.

How to describe this to a colleague: "Apply is blocked — state lock is held by another CI run, ID starts with 4f9b2e1a. Let me check if that run is still going before I force-unlock anything."

-/+ means destroy-then-create, not update — and this specific attribute cannot be changed in place.

Terraform's plan symbols each mean something specific:

• + — resource will be created
• - — resource will be destroyed
• ~ — resource will be updated in place
• -/+ — resource will be destroyed and then recreated (replacement)

The # forces replacement comment next to the ami line is Terraform explaining why replacement is required: the AWS provider knows that an EC2 instance's AMI can only be set at creation time — you cannot change which image an existing instance was built from without recreating it. The id line changing to (known after apply) confirms this is a brand-new instance getting a brand-new ID, not the same instance being modified.

Why this matters operationally: a replacement usually means downtime unless the resource is behind a load balancer with health checks, or the module uses create_before_destroy in a lifecycle block.

How to describe this to a colleague: "Heads up — this plan is going to replace the web instance, not just update it, because you can't swap the AMI in place. We should check if that causes downtime before I approve this apply."

A circular dependency — Terraform builds a dependency graph and cannot find a valid order when there's a loop in it.

Terraform determines the order to create/update/destroy resources by building a dependency graph from references in your configuration (e.g. security_group_id = aws_security_group.app.id creates an edge). A "Cycle" error means it found a loop: here, aws_security_group.app → aws_security_group_rule.allow_app_to_db → aws_security_group.db → aws_security_group_rule.allow_db_from_app → back to aws_security_group.app. There is no order in which all four resources could be created that satisfies every dependency.

The classic real-world cause: two security groups whose rules each reference the other group's ID directly inline (e.g. source_security_group_id = aws_security_group.db.id inside the app group's rule, and vice versa).

The fix: break the cycle by using separate aws_security_group_rule resources (rather than inline ingress/egress blocks) so each security group can be created first with no rules, and the cross-referencing rules are added afterward as independent resources — which is exactly the pattern shown in the error, so the actual bug is likely one specific rule referencing something that loops back.

How to describe this to a colleague: "Terraform's found a circular dependency between the two security groups — probably one rule referencing the other group in a way that loops back. I'll restructure the rules as separate resources."

The bucket exists — under this same account — but Terraform's state doesn't know about it, so it tried to create a duplicate.

BucketAlreadyOwnedByYou is AWS's specific error for "this bucket name already exists, and you already own it" — as opposed to a generic BucketAlreadyExists, which would mean someone else (in any AWS account, since S3 bucket names are globally unique) already claimed that name. The "OwnedByYou" distinction is important: it rules out a naming collision with a stranger's bucket and points to a state/tracking problem within your own account instead.

Common real causes:

• The bucket was created manually in the AWS Console or CLI, outside of Terraform, and never imported
• A previous terraform apply created the bucket successfully, but the run was interrupted before the state file was saved/uploaded (e.g. a killed CI job), so Terraform "forgot" it made this resource
• Someone deleted the resource from Terraform state (terraform state rm) without deleting the actual bucket

The fix: bring the existing resource under Terraform's management with terraform import aws_s3_bucket.artifacts my-app-artifacts rather than trying to re-create it.

How to describe this to a colleague: "The bucket already exists under our account — Terraform state just doesn't know about it. I'll import it instead of trying to create it fresh."