Repository navigation
Feature Request: Lifecycle pre-update hook for resource metadata modification #39188
Description
Terraform Version
Terraform v1.15.4Use Cases
Many organizations require resource metadata such as tags or labels to reflect the last modification performed through Terraform.
Common examples include:
- modified-datetime
- last-updated
- updated-by
- change-ticket
- deployment-reference
Today Terraform can set those values during resource creation, but it has no native mechanism to update them automatically when a resource is modified.
This makes governance, auditing and operational tracking difficult, especially in large environments where thousands of resources are managed through Terraform.
The end goal is to allow users to automatically update metadata whenever Terraform detects a resource change and applies an update.
Attempted Solutions
Several approaches were evaluated:
Using timestamps
tags = {
modified-datetime = timestamp()
}
This causes perpetual diffs because the timestamp changes on every plan.
Using external data sources
data "external" "git_date" {
program = ["bash", "-c", "git log -1 --format=%cs"]
}
This only reflects repository state and not actual Terraform resource updates.
Using null_resource triggers
resource "null_resource" "metadata" {
triggers = {
modified_datetime = timestamp()
}
}
This does not provide a way to update attributes of another resource before it is modified.
###Using lifecycle
lifecycle {
ignore_changes = [
tags["modified-datetime"]
]
}
This avoids drift but prevents Terraform from managing the value.
None of these approaches provide a generic and reliable mechanism to update resource metadata only when a resource is actually modified.
Proposal
Introduce a lifecycle hook executed immediately before a resource update operation.
Example:
resource "aws_s3_bucket" "example" {
bucket = "my-bucket"
tags = {
Environment = "prod"
}
lifecycle {
before_update {
tags = merge(self.tags, { modified-datetime = timestamp() }) }
}
}
References
Related discussions:
- Support for resource lifecycle hooks
- Support for update-time metadata tracking
- Common requests around automatic tagging and auditing
I was unable to find a Terraform Core feature that currently addresses this requirement.
Activity
jbardin commentedon Sep 11, 2026
Hi @gsi-eric,
What you're describing sounds similar to an
action_triggerusing thebefore_updateevent. That doesn't directly address changing an attribute of the resource however, so whatever action is taken must store metadata via another means.If storing the update time within the state is acceptable, using
replace_triggered_byfrom a state-only resource can suffice. Something like this for example:DIrectly modifying the resource isn't as simple as it sounds, because it depends on the structure and behavior of that particular resource. In Terraform, "tags" isn't metadata, it's just another attribute of the resource, and must be treated the same as any other. There was a proposal for actions to be able to modify a resource which hasn't been implemented yet, but because it requires prior knowledge of the resource and access to the APIs, it still needs to be implemented by the provider. That means most use cases could just be implemented directly in the normal plan+apply lifecycle, leaving little motivation for the large job of implementing an entirely new update mechanism for all resources.
A feature to directly modify the resource config based on the plan, which most closely matches your proposal, also has some fundamental problems which so far have no satisfactory solution. In your
before_updateexample, terraform doesn't know that the plan action is going to be an "update", or that there's even any action at all until after the resource is planned. Terraform doesn't create the plan, the providers create the plan, and once the plan is created, we can't change the configuration because that would invalidate the plan we just created.gsi-eric commentedon Sep 11, 2026
Thank you for the detailed explanation and the terraform_data example. It clarifies the limitations around modifying resource attributes during an update.
As a potential future improvement, it might be useful to have a dedicated resource that could be recreated whenever the main resource changes and that could separately attach or update its tags. This could allow Terraform to modify only the tagging section without changing the rest of the resource.
Do you think this strategy could be viable in future Terraform versions, or could it introduce issues such as circular dependencies between the resource and its tags?
Thank you again for your time and detailed response.
jbardin commentedon Sep 11, 2026
What you're describing was a proposed idea for the
actionfeature, but was not fully realized. There are two parts to that problem which made it unclear if the solution was worth the effort. Because that type of action would have side-effects in the resource state, it requires deep integration into the planning process, which was difficult for users to grasp. And because the action needed to be involved in the planning process, and have access to the same APIs as the final resource, the host provider would have to create the action themselves with significantly more development to implement special actions for each resource type. Since the provider needed to be so involved, and they already have the tools to customize their resources during plan, that is what I meant when I said it could be implemented directly in the normal plan+apply lifecycle.Having a separate managed resource doesn't work for the reason you hinted at, it creates a circular dependency which can't be resolved.
You could see the side-effects and their problems yourself now if you use an action (or even a provisioner) to update the tags out of band. It's possible to have a generic action of some sort read the tags then update them using something like the cloud provider's cli tool. This however won't be reflected in the state of the resource, meaning the resource can't also manage its own tags in the config without introducing drift. If you control all your own configuration, perhaps a pattern where no resource is allowed to directly manage its tags, and they are only updated via actions might work? That only possible if the provider has computed tags however, which aws does with the
tags_allfield, so that might be an option.