A configuration describes the infrastructure to create and how its parts relate. Rather than specifying a launch order, you define resources and use values from one resource to configure another. Terraform uses those references to infer dependencies and create resources in the required order. section 1.3.2
A web application and its dependencies
Suppose an application needs database credentials, while a DNS record needs its host’s IP address. Configure the application with values from the database and the DNS record with the host’s IP address. Those value references express the relationships: the application cannot use the database before it exists, and the DNS record needs an address from the host. section 1.3.2
Terraform configurations can be written in HCL, a human-friendly format, or JSON, which is easier to generate programmatically. Both formats describe resources, data sources, and other objects for Terraform to read. A configuration can span multiple files, and HCL and JSON files can share a directory. section 11.2
Configuration choices also affect testing and operations:
- Test a chosen configuration by launching its resources, checking the resulting infrastructure, and tearing it down. Group checks that can run against the same deployment; use separate configurations when requirements conflict, such as private logging storage versus a public static website. section 9.2.1
- Avoid hardcoding backend credentials in configuration. Depending on the backend, externally managed configuration files or environment variables can supply authentication; check the chosen backend’s documentation. section 6.4.4
Provider configuration has its own boundary: a provider’s schema defines which options it accepts. An API-backed provider may expose authentication parameters and allow environment variables as an alternative to setting them in the provider block. section 12.4.2
