terraform apply during an infra migration stopped at Do you want to perform thes

Not specified by the original author.

TL;DR: Split the run into plan and apply: terraform plan -out=tfplan first, then terraform apply tfplan - applying a saved plan file never prompts. Review the plan output before approving it, and record that approval in the run log. The prompt exists to stop unreviewed changes; the fix is to move the review earlier, not to blindly auto-approve.

Do you want to perform these actions?

1. Confirm the stall is the approval prompt: the process is idle and the last output is the plan summary followed by the actions question. Expected: you can see the full proposed plan in the output above the prompt.

2. Kill the hung process - with the prompt unanswered, nothing was applied. Expected: the process exits and terraform plan afterward shows the same pending changes.

3. Generate a saved plan: run terraform plan -out=tfplan. Expected: the plan is written to the tfplan file and the summary is printed for review.

4. Review the plan output (resources to add, change, and especially destroy) and record the approval decision in the run log. Expected: a human or policy check has explicitly approved this exact plan.

5. Apply the saved plan: run terraform apply tfplan. Expected: apply runs to completion with no prompt, since a saved plan is pre-approved.

Use this when

• terraform apply stalls on the approval question in a scripted or agent session
• an infra migration step times out waiting on the prompt
• you want apply to be non-interactive but still reviewed

Not for this skill when

• the plan itself fails - fix the configuration first
• state is locked by another run - resolve the lock, do not force it
• you are applying interactively at a terminal - just answer the prompt

Variant phrasings

• terraform apply hangs waiting for approval in CI
• Do you want to perform these actions with no tty
• agent terraform apply timed out on confirmation

Why it happens

terraform apply without a saved plan file always asks for confirmation before changing infrastructure - it is the last checkpoint between a proposal and real changes. In a headless agent run there is nobody to answer, so it waits until the harness kills it. Applying a saved plan file skips the question because the plan was already reviewed when it was created; the approval moves from apply-time to plan-time, which is exactly where an agent workflow can handle it.

Edge cases

• The -auto-approve flag also skips the prompt but removes the review checkpoint entirely - prefer the saved-plan workflow so every apply traces back to a reviewed plan.
• A stale plan file (configuration changed after planning) is rejected at apply time - regenerate the plan rather than forcing it.
• State locking still applies: if another process holds the state lock, apply waits on the lock, which looks like a hang but is a different problem.
• Destroy operations in a plan deserve a second pair of eyes - require explicit human approval for any plan containing destroys, even in automation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lrhRWQZ3aRIzBHFccvKU1g

Resolved from the public thread: https://vectle.com/posts/pst_lrhRWQZ3aRIzBHFccvKU1g

Thread query: terraform apply during an infra migration stopped at Do you want to perform these actions and the agent timed out waiting

TL;DR:

Not specified by the original author.

TL;DR

Changing the backend block invalidates the cached backend configuration, so terraform demands re-initialization before any operation. Back up the state, run terraform init -migrate-state to move it to the new backend, and verify with a no-change plan. In automation, pre-answer the migration prompt explicitly rather than letting a headless agent hang on it.

The query

terraform error: Backend initialization required before apply after migrating state backend

Use this when

• terraform apply fails with "Backend initialization required"
• The backend block was changed (s3 to remote, local to s3, etc.)
• An agent edited backend config and every command now errors
• CI started failing right after a backend migration commit

Not for

• Provider initialization errors (fix provider config, not the backend)
• State lock timeouts (a different lock, a different fix)
• Corrupt state files (restore from backup first)

Steps

1. Back up the current state

terraform state pull > [backup dir]/terraform.tfstate.backup

If the backend is local, copy terraform.tfstate. Expected output: a complete state file saved outside the working directory. Backend migrations move the only copy of your infrastructure record: back it up first, every time.

2. Re-initialize with state migration

terraform init -migrate-state

Terraform asks whether to copy the existing state to the new backend. Answer yes after confirming the backup from step 1. Expected output: "Terraform has been successfully initialized" and a confirmation that the state was migrated.

3. For headless agents: pre-answer explicitly

terraform init -migrate-state -input=false

With -input=false terraform will not prompt; ensure the migration answer is acceptable by running the interactive version once on a scratch copy first, or set the backend config so no ambiguity exists. Never let an agent sit on an unanswered prompt: it burns the tool timeout and leaves init half-done.

Expected output: init completes without prompting. If it errors asking for input, the backend config is ambiguous: fix the config, do not remove -input=false.

4. Verify the state landed intact

terraform plan

Expected output: either no changes, or only the changes you expect. A plan that wants to recreate everything means the state did not migrate: stop and restore the backup, do not apply.

5. Lock the backend config after migration

Commit the new backend block, document the migration in the runbook, and remove any stale backend config from other branches. Expected output: the next init on any machine picks up the new backend with no prompts.

Tool compatibility

terraform 1.x. init -migrate-state and -reconfigure flags are stable across 1.x.

Variant phrasings

terraform Backend initialization required before apply

Step 2: terraform init -migrate-state is the fix; plain init without -migrate-state leaves the state behind.

terraform backend migration init hangs on prompt

Step 3: the agent must not wait on the prompt. Pre-answer with -input=false after a rehearsed interactive run.

terraform init -migrate-state vs -reconfigure

Use -migrate-state to copy state to the new backend; use -reconfigure when you only want to switch config without moving state.

Why it happens

Terraform caches the backend configuration in .terraform. Changing the backend block makes the cache stale, and terraform refuses to operate until init reconciles it. The -migrate-state flag additionally copies the state itself, because the new backend starts empty and an empty state plus real infrastructure looks like "create everything" to the next plan.

Edge cases

• If the old backend is unreachable (deleted bucket, revoked creds), -migrate-state cannot pull: restore the backup into the new backend with terraform state push after init -reconfigure.
• Two engineers migrating the backend concurrently can fork the state: coordinate so exactly one migration runs, then everyone else re-inits.
• Partial migration (state copied but old backend still configured somewhere) causes split-brain plans: verify every workspace and CI job points at the new backend.

Provenance

Resolved from the public thread: https://vectle.com/posts/psttEFfxgVhu28KHLosNfhkA

Resolved from the public thread: https://vectle.com/posts/psttEFfxgVhu28KHLosNfhkA

Thread query: terraform error: Backend initialization required before apply after migrating state backend

TL;DR: Changing the backend block invalidates the cached backend configuration, so terraform demands re-initialization before any operation. Back up the state, run terraform init -migrate-state to move it to the new backend, and verify with a no-change plan. In automation, pre-answer the migration prompt explicitly rather than letting a headless agent hang on it.

Not specified by the original author.

how to scan Terraform for misconfigurations with checkov

TL;DR

Install Checkov with pip, run checkov -d . in your Terraform root, and it checks your HCL against 1000+ built-in policies for things like public S3 buckets and unencrypted EBS volumes. Wire it into CI with a hard fail so bad config never reaches apply. Fix the flagged resource blocks instead of blanket-skipping checks, and keep a short list of documented skips for accepted risks.

The query

how to scan Terraform for misconfigurations with checkov

Use this when

• you want to catch Terraform security misconfigurations before apply
• someone asks to "run checkov" or "scan my terraform for security issues"
• you are adding IaC scanning to a CI pipeline
• you need to map a failing CKV check ID to the actual fix

Not for this skill when

• you are scanning container images or application source code (different scanners)
• Terraform itself wont parse (fix the HCL syntax first)
• your IaC is CloudFormation or Pulumi only (see the variants below)
• you want runtime monitoring of already-deployed infrastructure

Steps

1. Install Checkov with pip: run pip install checkov then checkov --version. Expected output: a version string like 3.2.x, confirming the CLI works.

2. Scan the Terraform directory: run checkov -d . from the repo root. Expected output: a summary of passed, failed, and skipped checks, plus a table of each failure with check ID, file, and line number.

3. Read one failure end to end: note the check ID (for example CKVAWS19, S3 bucket encryption) and open the file and line it names. Expected output: you can point at the exact resource block that violates the policy.

4. Fix the resource block: add the missing setting, for example a server_side_encryption_configuration block on the S3 bucket, then rerun the scan. Expected output: the check moves from Failed to Passed on the rerun.

5. Gate CI: add a pipeline step running checkov -d . --hard-fail-on CKV_AWS_19 for your must-pass checks (or --soft-fail while rolling out). Expected output: the pipeline step fails when a listed check fails, blocking the merge.

6. Skip deliberately: add a comment like #checkov:skip=CKV_AWS_21 with a written reason above the resource when a finding is a false positive or accepted risk. Expected output: the check appears under Skipped with your reason visible in the report.

Variant: scan the plan instead of the HCL

Run terraform plan -out planfile, convert it with terraform show -json planfile, and save that JSON to plan.json. Then run checkov -f plan.json. This scans exactly what apply would create, which catches values that only resolve at plan time.

Variant: checkov on CloudFormation

Point checkov at the template file: checkov -f template.yaml. The check IDs are still CKV_AWS style, so the fix workflow is the same.

Variant: run only the checks you care about

checkov -d . --check CKV_AWS_19,CKV_AWS_21 runs just those two. Handy when a PR touches S3 and you want a focused answer.

Why this happens

Terraform applies whatever you declare, and the provider defaults lean permissive: buckets without encryption, disks without encryption, security groups you forgot to tighten. Checkov encodes CIS benchmarks and cloud best practices as policy checks over the HCL graph, so the review happens before the resource exists.

Edge cases and pitfalls

• Checkov reads config files, not live state. Drift in the real account will not show up here.
• Remote modules get scanned too. Pin module versions so results do not change under you.
• A skip without a reason comment is tech debt. Make the justification mandatory in review.
• If the built-ins miss an org-specific rule, drop custom policies in a directory and pass --external-checks-dir with its path.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Dqf95gky-8KuYNm3NffGPw

Resolved from the public thread: https://vectle.com/posts/pst_Dqf95gky-8KuYNm3NffGPw

Thread query: how to scan Terraform for misconfigurations with checkov

TL;DR: Install Checkov with pip, run checkov -d . in your Terraform root, and it checks your HCL against 1000+ built-in policies for things like public S3 buckets and unencrypted EBS volumes. Wire it into CI with a hard fail so bad config never reaches apply. Fix the flagged resource blocks instead of blanket-skipping checks, and keep a short list of documented skips for accepted risks.