You have built a complete infrastructure, but after an apply you have a practical question: What is my server's IP to open it in the browser? That's what outputs are for. In this subchapter, we'll see how to extract useful information and dive deeper into references, the mechanism that makes everything fit together.

Imagine you apply your configuration and Terraform creates 8 resources. How do you find out the server's public IP? You could go to the AWS console to look for it... but that's exactly what we want to avoid. Outputs (remember subchapter 10.1) make Terraform show you the important data at the end.

We create an outputs.tf file (or put it in any .tf) with the information we're interested in:

After a terraform apply, you'll see something like this at the end:

Now you have the URL ready to copy and paste into the browser! You can also check them at any time with terraform output (subchapter 11.4).

Notice url_web: we use interpolation ("http://${...}", subchapter 10.3) to build a complete URL by combining text with the IP value. Outputs don't have to be "raw" values: you can compose whatever you need.

Throughout the chapter, we've constantly used expressions like aws_vpc.principal.id. Let's understand what they are, because they are the central concept of Terraform.

A reference looks like this:

When you write aws_eip.web.public_ip, you're telling Terraform: "give me the public IP of the Elastic IP resource I called web."

References do two things at once:

1. Pass data from one resource to another. The instance needs the subnet ID, the Elastic IP needs the instance ID, etc. References connect that information.

2. Automatically create the dependency graph. As we saw in subchapter 9.4, Terraform deduces the creation order from the references. If A references B, then B is created before A.

Let's see it in our infrastructure:

Terraform reads this graph and creates things in order: first the VPC, then what depends on it, then the instance, and finally the Elastic IP. You don't specify the order: it deduces it from the references. And where possible, it parallelizes to go faster.

This is what makes Terraform magical. You don't write "do this, then this, then that" (that would be imperative, subchapter 9.2). You just describe the resources and how they relate, and Terraform figures out the correct order. That's why it's declarative.

Sometimes two resources depend on each other but without a direct data reference. In those rare cases, you can force the order with depends_on:

This tells it "don't create the instance until the Internet Gateway exists," even if you don't use any of its data. It's a last-resort tool: in 95% of cases, normal references are enough and are preferable. Use it only when Terraform can't deduce a dependency by itself.

• Outputs show useful information at the end (apply) and can be checked with terraform output; perfect for data like the server's IP or URL.
• You can compose outputs with interpolation (e.g., build a complete URL with "http://${...}").
• A reference (type.name.attribute) does two things: passes data between resources and creates the dependency (the creation order).
• Terraform builds a dependency graph from the references and deduces the order itself: you don't specify it. That's what makes it declarative.
• depends_on forces an order when there's no data reference; use it as a last resort, not by default.

In the last subchapter of the chapter, we'll make the leap to teamwork: how infrastructure changes are reviewed through Pull Requests and plan review.