# Fix terraform "Error: Invalid count argument"

**TL;DR:** Your `count` expression touches a value that is not known until apply time. Terraform has to decide how many instances to create before it plans anything, so `count` can only use values known up front. Rewrite the expression to use a variable or local that is known at plan time, or apply the upstream resource first with `-target` and then plan again.

## The error

```text
Error: Invalid count argument

  on main.tf line 39, in resource "aws_iam_role_policy_attachment" "lambda_vpc":
  39:   count = var.vpc_id != null ? 1 : 0

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created.
```

## Steps

1. Find what your `count` depends on. Read the expression and trace every value back to its source. Expected: you find a resource attribute, module output, or data source value that is only known after apply.
2. Introduce a plan-time boolean that mirrors the intent. For example, add `variable "enable_vpc" { type = bool }` and use `count = var.enable_vpc ? 1 : 0`, passing the value from your environment or tfvars. Expected: `count` no longer references anything computed.
3. Alternative when the value genuinely comes from another resource: apply the upstream resource first with `terraform apply -target=module.vpc`, then run a normal plan. Expected: the second plan sees the value as known and proceeds.
4. Run `terraform validate`. Expected: `Success! The configuration is valid.`

## When this applies

- `plan` fails with `Invalid count argument` and the message says the value depends on resource attributes not known until apply.
- A `count` (or module `count`) is derived from another resource's output, like `var.vpc_id != null` where the VPC is created in the same apply.

## When it does NOT apply

- `Invalid for_each argument`. Same family, different meta-argument; `for_each` needs static keys, not counts.
- `count` referencing module outputs that are already known at plan time. That works fine and does not error.

## Tool and version compatibility

- Terraform CLI 0.12+ through 1.x. The rule is unchanged across versions. Note the Terraform 1.16 deferred-actions experiment relaxes unknown-at-plan restrictions; on earlier versions the two-step apply is the way out.

## Why it happens

Terraform expands `count` into resource instances before it evaluates anything else. Expansion is a planning step, and planning cannot proceed on a maybe. A value that only exists after the upstream resource is created is a maybe, so Terraform refuses rather than guess.

## Edge cases and pitfalls

- Module-level `count` has the same rule: if a module input is unknown at plan, every `count` inside the module that touches it fails.
- The `-target` workaround is a two-step dance, not a fix. Prefer a plan-time boolean variable for anything permanent.
- `try()` does not help here. This is an expansion error, not an evaluation error.