Suppose a web application needs a database, a host, and a DNS record. A declarative configuration describes the infrastructure that should exist, rather than scripting checks and creation steps for each component. Terraform uses HashiCorp Configuration Language (HCL) to express that desired end state. section 1.3.1 section 1.2.1
The configuration also describes relationships. If the application uses credentials supplied by the database, Terraform can infer that the database must be ready first. If a DNS record uses the host’s IP address, that value establishes another dependency. Terraform turns these relationships into an ordered plan; you do not normally prescribe the launch order yourself. section 1.3.2 section 1.3
Deploying a change
Define the desired resources and their relationships in HCL. Run `terraform init` to download needed providers or modules, `terraform plan` to see the actions needed to align the workspace with the configuration, and `terraform apply` to run those actions. The configuration says what should exist; the plan shows what Terraform proposes to do. section 1.7 section 1.3.2
Figure 1.3 A diagram showing the relationship between the components in a web application
The web-application relationship diagram helps trace which components need values from others before Terraform orders their creation. section 1.3.2
An ordered plan cannot resolve a circular dependency on its own. If resource A must wait for B, B for C, and C for A, none can launch; Terraform needs a manual workaround. Declarative configuration removes much of the need to write deployment steps, but it does not remove the need to design workable dependencies. section 1.3.3 section 1.3.1
Keep the distinction clear inside HCL: functions transform data for configuration arguments, while resources and data sources handle operations that interact with system state. Use references to express dependencies, inspect the plan before applying it, and break dependency cycles when they arise. section 4.3 section 1.3.2 section 1.3.3
