Exporting All Attributes in Terraform Without Guesswork

You’ve probably hit this moment: you create a resource in Terraform, and now you want everything about it — IDs, ARNs, endpoints, computed values — without manually listing every single attribute.

Terraform doesn’t provide a single built-in switch for “export all attributes,” but there are a few reliable patterns that get you very close. Let’s walk through them, starting from the most practical approaches developers actually use.

Why exporting all attributes isn’t straightforward

Terraform’s design is intentional here. Outputs must be explicitly declared, which keeps configurations predictable and avoids accidentally exposing sensitive data.

But in real workflows — debugging, module development, or integration — you often need full visibility into a resource’s attributes.

Quick win: use terraform state show

If your goal is inspection rather than wiring outputs, this is the fastest path.

1terraform state show aws_instance.example

This prints all attributes Terraform knows about the resource, including computed values.

Useful when:

• Debugging unexpected values
• Exploring provider behavior
• Reverse-engineering resource outputs

Downside: it’s not structured for reuse in other modules or systems.

Structured export using outputs

Here’s where things get more reusable. Instead of exporting attributes one by one, you can often output the entire resource object.

1output "instance_all_attributes" {
2  value = aws_instance.example
3}

This works because Terraform resources are objects. When you output them directly, you get all accessible attributes.

But there’s a catch.

Not everything is included

Terraform only exposes attributes defined in the provider schema. Some internal or computed values might still not appear.

Making outputs cleaner with jsonencode

If you want a portable, API-friendly format:

1output "instance_json" {
2  value = jsonencode(aws_instance.example)
3}

This is especially useful when:

• Piping outputs into scripts
• Sending data to external systems
• Debugging complex nested structures

Exporting multiple resources dynamically

A common scenario: you’re using for_each and want all attributes for every instance.

1resource "aws_instance" "servers" {
2  for_each = var.server_map
3  ami           = each.value.ami
4  instance_type = each.value.type
5}
6
7output "all_servers" {
8  value = aws_instance.servers
9}

This returns a map of objects, each containing all attributes for each resource instance.

Filtering or reshaping attributes

Sometimes exporting everything is too noisy. You can reshape the output while still avoiding repetitive declarations.

1output "server_summary" {
2  value = {
3    for key, instance in aws_instance.servers :
4    key => {
5      id        = instance.id
6      public_ip = instance.public_ip
7      az        = instance.availability_zone
8    }
9  }
10}

This pattern strikes a balance: you’re not manually wiring every attribute, but you still control what gets exposed.

Deep dive: using terraform console

If you want to explore attributes interactively:

1terraform console

Then:

1aws_instance.example

This gives you a live object view, which is incredibly helpful when figuring out what can be exported.

A common mistake developers make

Trying to use wildcards or reflection-like behavior:

1# This does NOT work
2output "everything" {
3  value = aws_instance.example.*
4}

Terraform doesn’t support wildcard attribute expansion like some programming languages. You either:

• Output the full object
• Or explicitly map fields

Sensitive data considerations

Exporting all attributes can unintentionally expose secrets.

Mark outputs as sensitive when needed:

1output "instance_secure" {
2  value     = aws_instance.example
3  sensitive = true
4}

This prevents accidental logging or display in CLI output.

When exporting all attributes actually makes sense

Not every project benefits from this approach. It shines in:

• Module development and debugging
• Rapid prototyping
• Building reusable infrastructure modules
• Integrations with external automation tools

But in production modules, it’s usually better to expose only what consumers need.

A practical pattern for reusable modules

Here’s a hybrid approach many teams settle on:

1output "resource_full" {
2  value = aws_instance.example
3}
4
5output "resource_core" {
6  value = {
7    id  = aws_instance.example.id
8    arn = aws_instance.example.arn
9  }
10}

This gives flexibility without overwhelming downstream consumers.

Final thoughts

Terraform doesn’t hand you a one-liner to export all attributes — and that’s by design. But between direct resource outputs, JSON encoding, and state inspection, you can get everything you need without writing dozens of output blocks.

If you’re debugging, use terraform state show. If you’re building modules, output the full object and refine later. And if you’re integrating systems, JSON is your best friend.

Once you start treating Terraform resources as structured objects rather than individual fields, exporting attributes becomes much simpler — and far less repetitive.