• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Terraform
  • Install
  • Tutorials
    • About the Docs
    • Configuration Language
    • Terraform CLI
    • Terraform Cloud
    • Terraform Enterprise
    • CDK for Terraform
    • Provider Use
    • Plugin Development
    • Registry Publishing
    • Integration Program
  • Registry(opens in new tab)
  • Try Cloud(opens in new tab)
  • Sign up
Terraform Home

Internals

Skip to main content
  • Internals
  • Credentials Helpers
  • Debugging Terraform
  • Module Registry Protocol
  • Provider Network Mirror Protocol
  • Provider Registry Protocol
  • Resource Graph
  • Resource Lifecycle
  • Login Protocol
  • JSON Output Format
  • Remote Service Discovery
  • Provider Metadata

  • Terraform CLI

  • Configuration Language

  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  • Terraform Registry
    (opens in new tab)
  1. Developer
  2. Terraform
  3. Internals
  4. Resource Lifecycle
  • Terraform
  • v1.2.x
  • v1.1 and earlier

ยปResource Lifecycle

Resources have a strict lifecycle, and can be thought of as basic state machines. Understanding this lifecycle can help better understand how Terraform generates an execution plan, how it safely executes that plan, and what the resource provider is doing throughout all of this.

Advanced Topic! This page covers technical details of Terraform. You don't need to understand these details to effectively use Terraform. The details are documented here for those who wish to learn about them without having to go spelunking through the source code.

Lifecycle

A resource roughly follows the steps below:

  1. ValidateResource is called to do a high-level structural validation of a resource's configuration. The configuration at this point is raw and the interpolations have not been processed. The value of any key is not guaranteed and is just meant to be a quick structural check.

  2. Diff is called with the current state and the configuration. The resource provider inspects this and returns a diff, outlining all the changes that need to occur to the resource. The diff includes details such as whether or not the resource is being destroyed, what attribute necessitates the destroy, old values and new values, whether a value is computed, etc. It is up to the resource provider to have this knowledge.

  3. Apply is called with the current state and the diff. Apply does not have access to the configuration. This is a safety mechanism that limits the possibility that a provider changes a diff on the fly. Apply must apply a diff as prescribed and do nothing else to remain true to the Terraform execution plan. Apply returns the new state of the resource (or nil if the resource was destroyed).

  4. If a resource was just created and did not exist before, and the apply succeeded without error, then the provisioners are executed in sequence. If any provisioner errors, the resource is marked as tainted, so that it will be destroyed on the next apply.

Partial State and Error Handling

If an error happens at any stage in the lifecycle of a resource, Terraform stores a partial state of the resource. This behavior is critical for Terraform to ensure that you don't end up with any zombie resources: resources that were created by Terraform but no longer managed by Terraform due to a loss of state.

Edit this page on GitHub

On this page

  1. Resource Lifecycle
  2. Lifecycle
  3. Partial State and Error Handling
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)