github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/docs/language/meta-arguments/lifecycle.html.md (about) 1 --- 2 layout: "language" 3 page_title: "The lifecycle Meta-Argument - Configuration Language" 4 description: "The meta-arguments in a lifecycle block allow you to customize resource behavior." 5 --- 6 7 # The `lifecycle` Meta-Argument 8 9 > **Hands-on:** Try the [Lifecycle Management](https://learn.hashicorp.com/tutorials/terraform/resource-lifecycle?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn. 10 11 The general lifecycle for resources is described in the 12 [Resource Behavior](/docs/language/resources/behavior.html) page. Some details of 13 that behavior can be customized using the special nested `lifecycle` block 14 within a resource block body: 15 16 ```hcl 17 resource "azurerm_resource_group" "example" { 18 # ... 19 20 lifecycle { 21 create_before_destroy = true 22 } 23 } 24 ``` 25 26 ## Syntax and Arguments 27 28 `lifecycle` is a nested block that can appear within a resource block. 29 The `lifecycle` block and its contents are meta-arguments, available 30 for all `resource` blocks regardless of type. 31 32 The following arguments can be used within a `lifecycle` block: 33 34 * `create_before_destroy` (bool) - By default, when Terraform must change 35 a resource argument that cannot be updated in-place due to 36 remote API limitations, Terraform will instead destroy the existing object 37 and then create a new replacement object with the new configured arguments. 38 39 The `create_before_destroy` meta-argument changes this behavior so that 40 the new replacement object is created _first,_ and the prior object 41 is destroyed after the replacement is created. 42 43 This is an opt-in behavior because many remote object types have unique 44 name requirements or other constraints that must be accommodated for 45 both a new and an old object to exist concurrently. Some resource types 46 offer special options to append a random suffix onto each object name to 47 avoid collisions, for example. Terraform CLI cannot automatically activate 48 such features, so you must understand the constraints for each resource 49 type before using `create_before_destroy` with it. 50 51 Destroy provisioners of this resource will not run if `create_before_destroy` 52 is set to `true`. We may address this in the future, and this [GitHub issue](https://github.com/muratcelep/terraform/issues/13549) contains more details. 53 54 * `prevent_destroy` (bool) - This meta-argument, when set to `true`, will 55 cause Terraform to reject with an error any plan that would destroy the 56 infrastructure object associated with the resource, as long as the argument 57 remains present in the configuration. 58 59 This can be used as a measure of safety against the accidental replacement 60 of objects that may be costly to reproduce, such as database instances. 61 However, it will make certain configuration changes impossible to apply, 62 and will prevent the use of the `terraform destroy` command once such 63 objects are created, and so this option should be used sparingly. 64 65 Since this argument must be present in configuration for the protection to 66 apply, note that this setting does not prevent the remote object from 67 being destroyed if the `resource` block were removed from configuration 68 entirely: in that case, the `prevent_destroy` setting is removed along 69 with it, and so Terraform will allow the destroy operation to succeed. 70 71 * `ignore_changes` (list of attribute names) - By default, Terraform detects 72 any difference in the current settings of a real infrastructure object 73 and plans to update the remote object to match configuration. 74 75 The `ignore_changes` feature is intended to be used when a resource is 76 created with references to data that may change in the future, but should 77 not affect said resource after its creation. In some rare cases, settings 78 of a remote object are modified by processes outside of Terraform, which 79 Terraform would then attempt to "fix" on the next run. In order to make 80 Terraform share management responsibilities of a single object with a 81 separate process, the `ignore_changes` meta-argument specifies resource 82 attributes that Terraform should ignore when planning updates to the 83 associated remote object. 84 85 The arguments corresponding to the given attribute names are considered 86 when planning a _create_ operation, but are ignored when planning an 87 _update_. The arguments are the relative address of the attributes in the 88 resource. Map and list elements can be referenced using index notation, 89 like `tags["Name"]` and `list[0]` respectively. 90 91 ```hcl 92 resource "aws_instance" "example" { 93 # ... 94 95 lifecycle { 96 ignore_changes = [ 97 # Ignore changes to tags, e.g. because a management agent 98 # updates these based on some ruleset managed elsewhere. 99 tags, 100 ] 101 } 102 } 103 ``` 104 105 Instead of a list, the special keyword `all` may be used to instruct 106 Terraform to ignore _all_ attributes, which means that Terraform can 107 create and destroy the remote object but will never propose updates to it. 108 109 Only attributes defined by the resource type can be ignored. 110 `ignore_changes` cannot be applied to itself or to any other meta-arguments. 111 112 ## Literal Values Only 113 114 The `lifecycle` settings all affect how Terraform constructs and traverses 115 the dependency graph. As a result, only literal values can be used because 116 the processing happens too early for arbitrary expression evaluation.