An aws_eip resource uses for_each = toset(aws_instance.app[*].id). On a fresh environment, terraform plan fails because the for_each value depends on resource attributes that cannot be determined until apply. What is the recommended fix?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: An awseip resource uses foreach = toset(awsinstance.app[].id). On a fresh environment, terraform plan fails because the foreach value depends on resource attributes that cannot be determined until apply. What is the recommended fix? Correct Answer: Key foreach on values known in configuration, such as the names used to create the instances, and look up IDs in the block Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/hashicorp/terraform-pro-002/TERRAFORM-PRO-002-e1-q019.webp)
Short Explanation
for_each has to know the guest list before the party starts. Instance IDs don't exist until after apply, so you can't use them as name tags. Use names you already have in your configuration and fetch the IDs later.
Full Explanation
Terraform must know every for_each key during planning so it can determine the full set of instance addresses. Instance IDs are computed by the provider during apply, so on a fresh environment they are unknown at plan time and Terraform refuses to plan. The documented remedy is to key for_each on values defined in configuration, such as the same map or set of names used to create the instances, and reference the computed attribute inside the block, for example instance = aws_instance.app[each.key].id when the instances also use for_each over those names. Only the keys must be known; attribute values inside the block may be unknown. depends_on controls ordering of operations but cannot make an unknown value known during planning. try() handles evaluation errors, not unknown values, so it does not resolve the problem. create_before_destroy affects replacement order and has no bearing on whether an attribute is known at plan time. Exam caveat: -target can apply the instances first as a one-off workaround, but HashiCorp recommends it only for exceptional recovery, not as the design. Operational check: run terraform plan on an empty state and confirm it lists one aws_eip instance per configured name.