Given that Ref and Fn::GetAtt already order resource creation in an AWS CloudFormation template, when do you still need an explicit DependsOn attribute?

## The graph you get for free CloudFormation does not deploy resources in the order they appear in the template. It reads every intrinsic function, records which resource each one points at, and derives a directed graph. If `Instance` contains `!Ref Subnet`, then `Subnet` is created first. Resources with no edge between them are created concurrently, which is why a large stack does not take the sum of its resource creation times. Three things create an edge: - `Ref` naming another resource, - `Fn::GetAtt` naming another resource, - `Fn::Sub` whose string contains `${Logical}` or `${Logical.Attribute}`. What does **not** create an edge: sitting next to something in the file, sharing a `Condition`, referring to the same parameter, or `Fn::ImportValue` — that reads another *stack's* export and says nothing about ordering inside this one. ## Where the graph is blind The graph only knows about data flow. It cannot know that a resource must be *functional*, not merely *created*, before another starts. Two cases dominate real templates. **Internet gateway attachment.** You declare a VPC, an `AWS::EC2::InternetGateway`, an `AWS::EC2::VPCGatewayAttachment` joining them, and a route in a route table. An EC2 instance in a public subnet references the subnet and a security group — never the attachment. So CloudFormation may create the instance while the gateway is still unattached, its user data tries to reach a package repository, and the bootstrap fails intermittently. `DependsOn: AttachGateway` on the instance, or on the route, fixes it. This is the example AWS itself documents. **A policy the workload needs but does not reference.** A Lambda function or an instance profile references the *role*. An `AWS::IAM::Policy` with `Roles: [!Ref AppRole]` references the role too — so both depend on the role and neither depends on the other. The function can therefore be created, and invoked, before its permissions are attached. `DependsOn` on the consumer, naming the policy, closes that window. Other cases in the same family: a resource that needs a custom resource's side effect to have completed, or a database that must be seeded before something starts reading it. ```yaml AttachGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref Vpc InternetGatewayId: !Ref Igw Web: Type: AWS::EC2::Instance DependsOn: AttachGateway ``` ## Syntax and semantics `DependsOn` is a **resource attribute**, a sibling of `Type` and `Properties`, not a property. Its value is a logical ID or a list of them. It affects create ordering, update ordering, and — reversed — delete ordering: CloudFormation deletes dependents before their dependencies, which is why a stack teardown does not race the way a hand-rolled script does. It does not make a value available. `DependsOn` is pure ordering; if you also need the other resource's ARN, you still write the reference, and once you do, the `DependsOn` is redundant. ## The cost of overusing it A `DependsOn` sprinkled defensively on every resource turns a parallel deployment into a serial one. On a stack of a hundred resources that is the difference between a few minutes and a long coffee. It also hides intent: a reader cannot tell which edges are real requirements and which are superstition. Add one only when you can name the failure it prevents. ## Circular dependencies The flip side of the graph is that a cycle is fatal — CloudFormation fails the stack with a *circular dependency between resources* error naming the logical IDs involved. Two security groups that reference each other are the classic case: group A allows traffic from B, and B allows traffic from A. The fix is not `DependsOn` — adding ordering to a cycle only makes the cycle explicit. Instead break the reference: declare the groups with no cross-references and add standalone `AWS::EC2::SecurityGroupIngress` resources that each point at both groups. The trick generalises — move the mutual association into a third resource that depends on both sides. ## What to say in an interview The crisp answer is: references create ordering automatically, `DependsOn` exists for ordering that references cannot express, the two examples everyone hits are gateway attachment and IAM policy attachment, and overuse costs parallelism. If you can add that a cycle is broken by extracting the association rather than by adding `DependsOn`, you have covered the whole topic.