1--- 2layout: "language" 3page_title: "References to Values - Configuration Language" 4--- 5 6# References to Named Values 7 8> **Hands-on:** Try the [Create Dynamic Expressions](https://learn.hashicorp.com/tutorials/terraform/expressions?in=terraform/configuration-language&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial on HashiCorp Learn. 9 10Terraform makes several kinds of named values available. Each of these names is 11an expression that references the associated value; you can use them as 12standalone expressions, or combine them with other expressions to compute new 13values. 14 15## Types of Named Values 16 17The main kinds of named values available in Terraform are: 18 19- Resources 20- Input variables 21- Local values 22- Child module outputs 23- Data sources 24- Filesystem and workspace info 25- Block-local values 26 27The sections below explain each kind of named value in detail. 28 29Although many of these names use dot-separated paths that resemble 30[attribute notation](./types.html#indices-and-attributes) for elements of object values, they are not 31implemented as real objects. This means you must use them exactly as written: 32you cannot use square-bracket notation to replace the dot-separated paths, and 33you cannot iterate over the "parent object" of a named entity; for example, you 34cannot use `aws_instance` in a `for` expression to iterate over every AWS 35instance resource. 36 37### Resources 38 39`<RESOURCE TYPE>.<NAME>` represents a [managed resource](/docs/language/resources/index.html) of 40the given type and name. 41 42The value of a resource reference can vary, depending on whether the resource 43uses `count` or `for_each`: 44 45- If the resource doesn't use `count` or `for_each`, the reference's value is an 46 object. The resource's attributes are elements of the object, and you can 47 access them using [dot or square bracket notation](./types.html#indices-and-attributes). 48- If the resource has the `count` argument set, the reference's value is a 49 _list_ of objects representing its instances. 50- If the resource has the `for_each` argument set, the reference's value is a 51 _map_ of objects representing its instances. 52 53Any named value that does not match another pattern listed below 54will be interpreted by Terraform as a reference to a managed resource. 55 56For more information about how to use resource references, see 57[references to resource attributes](#references-to-resource-attributes) below. 58 59### Input Variables 60 61`var.<NAME>` is the value of the [input variable](/docs/language/values/variables.html) of the given name. 62 63If the variable has a type constraint (`type` argument) as part of its 64declaration, Terraform will automatically convert the caller's given value 65to conform to the type constraint. 66 67For that reason, you can safely assume that a reference using `var.` will 68always produce a value that conforms to the type constraint, even if the caller 69provided a value of a different type that was automatically converted. 70 71In particular, note that if you define a variable as being of an object type 72with particular attributes then only _those specific attributes_ will be 73available in expressions elsewhere in the module, even if the caller actually 74passed in a value with additional attributes. You must define in the type 75constraint all of the attributes you intend to use elsewhere in your module. 76 77### Local Values 78 79`local.<NAME>` is the value of the [local value](/docs/language/values/locals.html) of the given name. 80 81Local values can refer to other local values, even within the same `locals` 82block, as long as you don't introduce circular dependencies. 83 84### Child Module Outputs 85 86`module.<MODULE NAME>` is an value representing the results of 87[a `module` block](/docs/language/modules/syntax.html). 88 89If the corresponding `module` block does not have either `count` nor `for_each` 90set then the value will be an object with one attribute for each output value 91defined in the child module. To access one of the module's 92[output values](/docs/language/values/outputs.html), use `module.<MODULE NAME>.<OUTPUT NAME>`. 93 94If the corresponding `module` uses `for_each` then the value will be a map 95of objects whose keys correspond with the keys in the `for_each` expression, 96and whose values are each objects with one attribute for each output value 97defined in the child module, each representing one module instance. 98 99If the corresponding module uses `count` then the result is similar to for 100`for_each` except that the value is a _list_ with the requested number of 101elements, each one representing one module instance. 102 103### Data Sources 104 105`data.<DATA TYPE>.<NAME>` is an object representing a 106[data resource](/docs/language/data-sources/index.html) of the given data 107source type and name. If the resource has the `count` argument set, the value 108is a list of objects representing its instances. If the resource has the `for_each` 109argument set, the value is a map of objects representing its instances. 110 111For more information, see 112[References to Resource Attributes](#references-to-resource-attributes), which 113also applies to data resources aside from the addition of the `data.` prefix 114to mark the reference as for a data resource. 115 116### Filesystem and Workspace Info 117 118* `path.module` is the filesystem path of the module where the expression 119 is placed. 120* `path.root` is the filesystem path of the root module of the configuration. 121* `path.cwd` is the filesystem path of the current working directory. In 122 normal use of Terraform this is the same as `path.root`, but some advanced 123 uses of Terraform run it from a directory other than the root module 124 directory, causing these paths to be different. 125* `terraform.workspace` is the name of the currently selected 126 [workspace](/docs/language/state/workspaces.html). 127 128Use the values in this section carefully, because they include information 129about the context in which a configuration is being applied and so may 130inadvertently hurt the portability or composability of a module. 131 132For example, if you use `path.cwd` directly to populate a path into a resource 133argument then later applying the same configuration from a different directory 134or on a different computer with a different directory structure will cause 135the provider to consider the change of path to be a change to be applied, even 136if the path still refers to the same file. 137 138Similarly, if you use any of these values as a form of namespacing in a shared 139module, such as using `terraform.workspace` as a prefix for globally-unique 140object names, it may not be possible to call your module more than once in 141the same configuration. 142 143Aside from `path.module`, we recommend using the values in this section only 144in the root module of your configuration. If you are writing a shared module 145which needs a prefix to help create unique names, define an input variable 146for your module and allow the calling module to define the prefix. The 147calling module can then use `terraform.workspace` to define it if appropriate, 148or some other value if not: 149 150```hcl 151module "example" { 152 # ... 153 154 name_prefix = "app-${terraform-workspace}" 155} 156``` 157 158### Block-Local Values 159 160Within the bodies of certain blocks, or in some other specific contexts, 161there are other named values available beyond the global values listed above. 162These local names are described in the documentation for the specific contexts 163where they appear. Some of most common local names are: 164 165- `count.index`, in resources that use 166 [the `count` meta-argument](/docs/language/meta-arguments/count.html). 167- `each.key` / `each.value`, in resources that use 168 [the `for_each` meta-argument](/docs/language/meta-arguments/for_each.html). 169- `self`, in [provisioner](/docs/language/resources/provisioners/syntax.html) and 170 [connection](/docs/language/resources/provisioners/connection.html) blocks. 171 172-> **Note:** Local names are often referred to as _variables_ or 173_temporary variables_ in their documentation. These are not [input 174variables](/docs/language/values/variables.html); they are just arbitrary names 175that temporarily represent a value. 176 177The names in this section relate to top-level configuration blocks only. 178If you use [`dynamic` blocks](dynamic-blocks.html) to dynamically generate 179resource-type-specific _nested_ blocks within `resource` and `data` blocks then 180you'll refer to the key and value of each element differently. See the 181`dynamic` blocks documentation for details. 182 183## Named Values and Dependencies 184 185Constructs like resources and module calls often use references to named values 186in their block bodies, and Terraform analyzes these expressions to automatically 187infer dependencies between objects. For example, an expression in a resource 188argument that refers to another managed resource creates an implicit dependency 189between the two resources. 190 191## References to Resource Attributes 192 193The most common reference type is a reference to an attribute of a resource 194which has been declared either with a `resource` or `data` block. Because 195the contents of such blocks can be quite complicated themselves, expressions 196referring to these contents can also be complicated. 197 198Consider the following example resource block: 199 200```hcl 201resource "aws_instance" "example" { 202 ami = "ami-abc123" 203 instance_type = "t2.micro" 204 205 ebs_block_device { 206 device_name = "sda2" 207 volume_size = 16 208 } 209 ebs_block_device { 210 device_name = "sda3" 211 volume_size = 20 212 } 213} 214``` 215 216The documentation for [`aws_instance`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance) 217lists all of the arguments and nested blocks supported for this resource type, 218and also lists a number of attributes that are _exported_ by this resource 219type. All of these different resource type schema constructs are available 220for use in references, as follows: 221 222* The `ami` argument set in the configuration can be used elsewhere with 223 the reference expression `aws_instance.example.ami`. 224* The `id` attribute exported by this resource type can be read using the 225 same syntax, giving `aws_instance.example.id`. 226* The arguments of the `ebs_block_device` nested blocks can be accessed using 227 a [splat expression](./splat.html). For example, to obtain a list of 228 all of the `device_name` values, use 229 `aws_instance.example.ebs_block_device[*].device_name`. 230* The nested blocks in this particular resource type do not have any exported 231 attributes, but if `ebs_block_device` were to have a documented `id` 232 attribute then a list of them could be accessed similarly as 233 `aws_instance.example.ebs_block_device[*].id`. 234* Sometimes nested blocks are defined as taking a logical key to identify each 235 block, which serves a similar purpose as the resource's own name by providing 236 a convenient way to refer to that single block in expressions. If `aws_instance` 237 had a hypothetical nested block type `device` that accepted such a key, it 238 would look like this in configuration: 239 240 ```hcl 241 device "foo" { 242 size = 2 243 } 244 device "bar" { 245 size = 4 246 } 247 ``` 248 249 Arguments inside blocks with _keys_ can be accessed using index syntax, such 250 as `aws_instance.example.device["foo"].size`. 251 252 To obtain a map of values of a particular argument for _labelled_ nested 253 block types, use a [`for` expression](./for.html): 254 `{for k, device in aws_instance.example.device : k => device.size}`. 255 256When a resource has the 257[`count`](/docs/language/meta-arguments/count.html) 258argument set, the resource itself becomes a _list_ of instance objects rather than 259a single object. In that case, access the attributes of the instances using 260either [splat expressions](./splat.html) or index syntax: 261 262* `aws_instance.example[*].id` returns a list of all of the ids of each of the 263 instances. 264* `aws_instance.example[0].id` returns just the id of the first instance. 265 266When a resource has the 267[`for_each`](/docs/language/meta-arguments/for_each.html) 268argument set, the resource itself becomes a _map_ of instance objects rather than 269a single object, and attributes of instances must be specified by key, or can 270be accessed using a [`for` expression](./for.html). 271 272* `aws_instance.example["a"].id` returns the id of the "a"-keyed resource. 273* `[for value in aws_instance.example: value.id]` returns a list of all of the ids 274 of each of the instances. 275 276Note that unlike `count`, splat expressions are _not_ directly applicable to resources managed with `for_each`, as splat expressions must act on a list value. However, you can use the `values()` function to extract the instances as a list and use that list value in a splat expression: 277 278* `values(aws_instance.example)[*].id` 279 280### Sensitive Resource Attributes 281 282When defining the schema for a resource type, a provider developer can mark 283certain attributes as _sensitive_, in which case Terraform will show a 284placeholder marker `(sensitive)` instead of the actual value when rendering 285a plan involving that attribute. 286 287A provider attribute marked as sensitive behaves similarly to an 288[an input variable declared as sensitive](/docs/language/values/variables.html#suppressing-values-in-cli-output), 289where Terraform will hide the value in the plan and apply messages and will 290also hide any other values you derive from it as sensitive. 291However, there are some limitations to that behavior as described in 292[Cases where Terraform may disclose a sensitive variable](/docs/language/values/variables.html#cases-where-terraform-may-disclose-a-sensitive-variable). 293 294If you use a sensitive value from a resource attribute as part of an 295[output value](/docs/language/values/outputs.html) then Terraform will require 296you to also mark the output value itself as sensitive, to confirm that you 297intended to export it. 298 299Terraform will still record sensitive values in the [state](/docs/language/state/index.html), 300and so anyone who can access the state data will have access to the sensitive 301values in cleartext. For more information, see 302[_Sensitive Data in State_](/docs/language/state/sensitive-data.html). 303 304-> **Note:** Treating values derived from a sensitive resource attribute as 305sensitive themselves was introduced in Terraform v0.15. Earlier versions of 306Terraform will obscure the direct value of a sensitive resource attribute, 307but will _not_ automatically obscure other values derived from sensitive 308resource attributes. 309 310### Values Not Yet Known 311 312When Terraform is planning a set of changes that will apply your configuration, 313some resource attribute values cannot be populated immediately because their 314values are decided dynamically by the remote system. For example, if a 315particular remote object type is assigned a generated unique id on creation, 316Terraform cannot predict the value of this id until the object has been created. 317 318To allow expressions to still be evaluated during the plan phase, Terraform 319uses special "unknown value" placeholders for these results. In most cases you 320don't need to do anything special to deal with these, since the Terraform 321language automatically handles unknown values during expressions, so that 322for example adding a known value to an unknown value automatically produces 323an unknown value as the result. 324 325However, there are some situations where unknown values _do_ have a significant 326effect: 327 328* The `count` meta-argument for resources cannot be unknown, since it must 329 be evaluated during the plan phase to determine how many instances are to 330 be created. 331 332* If unknown values are used in the configuration of a data resource, that 333 data resource cannot be read during the plan phase and so it will be deferred 334 until the apply phase. In this case, the results of the data resource will 335 _also_ be unknown values. 336 337* If an unknown value is assigned to an argument inside a `module` block, 338 any references to the corresponding input variable within the child module 339 will use that unknown value. 340 341* If an unknown value is used in the `value` argument of an output value, 342 any references to that output value in the parent module will use that 343 unknown value. 344 345* Terraform will attempt to validate that unknown values are of suitable 346 types where possible, but incorrect use of such values may not be detected 347 until the apply phase, causing the apply to fail. 348 349Unknown values appear in the `terraform plan` output as `(not yet known)`. 350