A terraform apply fails with an error beginning "Error: Cycle:" that names two aws_security_group resources. What has gone wrong, and how do you break it?

## Why a cycle is fatal rather than merely awkward Terraform plans and applies by topologically sorting a directed acyclic graph. A topological sort exists only if the graph has no cycles: if A must come after B and B must come after A, there is no first node, so there is nothing Terraform can legally do. It refuses up front rather than picking arbitrarily, and the error names every node in the loop: ``` Error: Cycle: aws_security_group.app, aws_security_group.db ``` That member list is the most useful part of the message — the loop is exactly those nodes, and the edge you need to remove is between two of them. ## The security-group case, which is most of them in practice The AWS provider lets you write rules two ways: as `ingress` / `egress` blocks inside `aws_security_group`, or as separate `aws_security_group_rule` resources. Inline blocks are part of the group's own body, so a rule that allows traffic *from* another group makes the whole group depend on that other group. Two services that talk to each other in both directions therefore produce a mutual dependency: ```hcl resource "aws_security_group" "app" { ingress { security_groups = [aws_security_group.db.id] # app -> db } } resource "aws_security_group" "db" { ingress { security_groups = [aws_security_group.app.id] # db -> app => Cycle } } ``` The standalone-rule form breaks it because a rule is a third node: `aws_security_group_rule.db_from_app` references both groups, so both edges point *downward* from the groups to the rules and nothing points back. Terraform creates both groups concurrently, then both rules. This is the general shape of every cycle fix — find the piece of the relationship that does not have to live inside either object, and give it its own node. ## The other common causes **A hand-written `depends_on` that points back up the chain.** Someone adds `depends_on = [aws_instance.app]` to a resource the instance already references. The implicit edge goes one way, the explicit edge goes the other, and the graph closes. When a cycle appears immediately after someone "fixed an ordering bug", look at the `depends_on` they added first. **A module-level ordering loop.** Two modules that each consume an output of the other cannot both go first; the fix is the same as with resources — hoist the shared value out into a resource or variable both can read, so the estate becomes a fan-out instead of a ring. **Replacement ordering.** `create_before_destroy` inverts a node's create/destroy ordering, and Terraform requires that inversion to be consistent across everything the resource depends on; a partially applied inversion can present as a cycle. If the loop appears only when a resource is being replaced and not on a fresh create, this is the direction to look. ## Diagnosing when the error is not obvious With two named nodes, the error is usually enough — open both and find the mutual reference. With a long member list, or with generated configuration where the reference is buried in a `for` expression, render the graph: ``` terraform graph -draw-cycles | dot -Tsvg > graph.svg ``` `-draw-cycles` highlights the offending edges, which is faster than reading raw DOT. Note that Terraform's graph output is verbose — a real root module produces a picture too dense to read end to end — so use it to confirm a suspicion rather than to browse. ## What not to do The reflex fix that never works is adding *more* `depends_on` to "force" an order. A cycle is an over-constrained graph; adding edges tightens it further. The only fixes are to remove an edge (drop the reference, hardcode nothing, extract the value) or to split a node into two so the edges no longer close. Equally, do not solve it by applying twice — commenting out one side, applying, then uncommenting. It works once, on your machine, and leaves a configuration that cannot be created from scratch in a fresh account. That is exactly the property IaC exists to guarantee, and a reviewer should reject it.