Two security groups each allow traffic from the other, and both rules are written as inline ingress blocks that reference the other group's ID. terraform plan now fails with a Cycle error naming both groups. Which change resolves the error?
Select an answer to reveal the explanation.
Short Explanation
It's a chicken-and-egg problem: each group needs the other's ID before it can exist. You break it by letting both groups be born empty, then add the rules as their own resources once both IDs are known. Adding depends_on just draws another arrow in the same circle.
Full Explanation
Terraform builds a dependency graph from references, and each node must be created after everything it references. Inline rules that cite the other group make each security group depend on the other, which is a cycle; no order exists, so planning fails. Moving the cross-referencing rules into standalone rule resources breaks the loop: both groups are created first with no reference to each other, and each rule resource then references the two group IDs that already exist. Many providers offer separate rule resources precisely for this pattern, and it is the common fix for mutual references. depends_on adds edges to the graph; it cannot remove the references that form the cycle, so it never fixes one and may add new ones. Placing both groups in a module does not change their references, and the cycle persists within the module. -parallelism only limits how many operations run concurrently during a graph walk; it cannot walk a graph that has no valid order. Exam caveat: mixing inline rules and standalone rule resources for the same group causes the two to fight over the rule set, so choose one style per group. Operational check: after the refactor, run terraform validate and terraform plan and confirm the Cycle error is gone.