Terraform

Avoid common Terraform mistakes — state corruption, count vs for_each, lifecycle traps, and dependency ordering.

Security Scan

Instruction-only Terraform best-practices skill that is internally consistent with its stated purpose and requests no extra credentials or installs.

Purpose & Capability

Name, description, and content all focus on Terraform best practices; the single declared requirement (terraform binary) is appropriate and proportional.

Instruction Scope

SKILL.md contains guidance about state, lifecycle, dependencies, modules, import, and common mistakes; it does not instruct the agent to read unrelated files, exfiltrate data, or call external endpoints. It does mention remote backends (S3/GCS/DynamoDB/Terraform Cloud) only as recommendations, which is expected for Terraform guidance.

Install Mechanism

No install spec and no code files — this is instruction-only, which minimizes disk writes and execution risk.

Credentials

The skill declares no environment variables or credentials. References to cloud backends are advisory; no unrelated secrets or credentials are requested.

Persistence & Privilege

Skill is not forced-always, is user-invocable, and allows autonomous invocation (the platform default). It does not request persistent system changes or modify other skills' configs.

Assessment

This is a low-risk, instruction-only skill providing Terraform advice. It won't install code or ask for credentials, but be aware: if you let an agent execute terraform commands on your machine, those commands will use whatever local cloud credentials and access the actual infrastructure. Only allow command execution in a safe environment (e.g., CI or a sandbox), review plans before any apply/destroy, avoid granting broad cloud credentials to the agent, and prefer running destructive commands yourself after inspection. If you need stricter control, restrict the agent's ability to run shell commands or run the advice in a read-only/test environment first.

State Management

• Local state gets corrupted/lost — use remote backend (S3, GCS, Terraform Cloud)
• Multiple people running simultaneously — enable state locking with DynamoDB or equivalent
• Never edit state manually — use terraform state mv, rm, import
• State contains secrets in plain text — encrypt at rest, restrict access

Count vs for_each

• count uses index — removing item 0 shifts all indices, forces recreation
• for_each uses keys — stable, removing one doesn't affect others
• Can't use both on same resource — choose one
• for_each requires set or map — toset() to convert list

Lifecycle Rules

• prevent_destroy = true — blocks accidental deletion, must be removed to destroy
• create_before_destroy = true — new resource created before old destroyed, for zero downtime
• ignore_changes for external modifications — ignore_changes = [tags] ignores drift
• replace_triggered_by to force recreation — when dependency changes

Dependencies

• Implicit via reference — aws_instance.foo.id creates automatic dependency
• depends_on for hidden dependencies — when reference isn't in config
• depends_on accepts list — depends_on = [aws_iam_role.x, aws_iam_policy.y]
• Data sources run during plan — may fail if resource doesn't exist yet

Data Sources

• Data sources read existing resources — don't create
• Runs at plan time — dependency must exist before plan
• Use depends_on if implicit dependency not clear — or plan fails
• Consider using resource output instead — more explicit

Modules

• Pin module versions — source = "org/name/aws?version=1.2.3"
• terraform init -upgrade to update — doesn't auto-update
• Module outputs must be explicitly defined — can't access internal resources from outside
• Nested modules: output must bubble up — each layer needs to export

Variables

• No type = any — explicit type = string, list(string), map(object({...}))
• sensitive = true hides from output — but still in state file
• validation block for constraints — custom error message
• nullable = false to reject null — default is nullable

Common Mistakes

• terraform destroy is permanent — no undo, use -target carefully
• Plan succeeded ≠ apply succeeds — API errors, quotas, permissions discovered at apply
• Renaming resource = delete + create — use moved block or terraform state mv
• Workspaces not for environments — use separate state files/backends per env
• Provisioners are last resort — use cloud-init, user_data, or config management instead

Import

• terraform import aws_instance.foo i-1234 — imports existing resource to state
• Doesn't generate config — must write matching resource block manually
• import block (TF 1.5+) — declarative import in config
• Plan after import to verify — should show no changes if config matches