terraform Import tfplan page title tfplan Imports Sentinel HCP Terraform The tfplan import provides access to a Terraform plan A Terraform plan is the file created as a result of terraform plan and is the input to terraform apply The plan represents the changes that Terraform needs to make to infrastructure to reach the desired state represented by the configuration

Answer:
---
page_title: tfplan - Imports - Sentinel - HCP Terraform
description: >-
  The tfplan import provides access to a Terraform plan. A Terraform plan is the
  file created as a result of `terraform plan` and is the input to `terraform
  apply`. The plan represents the changes that Terraform needs to make to
  infrastructure to reach the desired state represented by the configuration.
---

# Import: tfplan

~> **Warning:** The `tfplan` import is now deprecated and will be permanently removed in August 2025.
We recommend that you start using the updated [tfplan/v2](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfplan-v2) import as soon as possible to avoid disruptions.
The `tfplan/v2` import offers improved functionality and is designed to better support your policy enforcement needs.

The `tfplan` import provides access to a Terraform plan. A Terraform plan is the
file created as a result of `terraform plan` and is the input to `terraform
apply`. The plan represents the changes that Terraform needs to make to
infrastructure to reach the desired state represented by the configuration.

In addition to the diff data available in the plan, there is an
[`applied`](#value-applied) state available that merges the plan with the state
to create the planned state after apply.

Finally, this import also allows you to access the configuration files and the
Terraform state at the time the plan was run. See the section on [accessing a
plan's state and configuration
data](#accessing-a-plan-39-s-state-and-configuration-data) for more information.

<!-- BEGIN: TFC:only name:pnp-callout -->
@include 'tfc-package-callouts/policies.mdx'
<!-- END: TFC:only name:pnp-callout -->

## Namespace Overview

The following is a tree view of the import namespace. For more detail on a
particular part of the namespace, see below.

-> Note that the root-level alias keys shown here (`data`, `path`, and
`resources`) are shortcuts to a [module namespace](#namespace-module) scoped to
the root module. For more details, see the section on [root namespace
aliases](#root-namespace-aliases).

```
tfplan
├── module() (function)
│   └── (module namespace)
│       ├── path ([]string)
│       ├── data
│       │   └── TYPE.NAME[NUMBER]
│       │       ├── applied (map of keys)
│       │       └── diff
│       │           └── KEY
│       │               ├── computed (bool)
│       │               ├── new (string)
│       │               └── old (string)
│       └── resources
│           └── TYPE.NAME[NUMBER]
│               ├── applied (map of keys)
│               ├── destroy (bool)
│               ├── requires_new (bool)
│               └── diff
│                   └── KEY
│                       ├── computed (bool)
│                       ├── new (string)
│                       └── old (string)
├── module_paths ([][]string)
├── terraform_version (string)
├── variables (map of keys)
│
├── data (root module alias)
├── path (root module alias)
├── resources (root module alias)
│
├── config (tfconfig namespace alias)
└── state (tfstate import alias)
```

## Namespace: Root

The root-level namespace consists of the values and functions documented below.

In addition to this, the root-level `data`, `path`, and `resources` keys alias
to their corresponding namespaces or values within the [module
namespace](#namespace-module).

### Accessing a Plan's State and Configuration Data

The `config` and `state` keys alias to the [`tfconfig`][import-tfconfig] and
[`tfstate`][import-tfstate] namespaces, respectively, with the data sourced from
the Terraform _plan_ (as opposed to actual configuration and state).

[import-tfconfig]: /terraform/cloud-docs/policy-enforcement/sentinel/import/tfconfig

[import-tfstate]: /terraform/cloud-docs/policy-enforcement/sentinel/import/tfstate

-> Note that these aliases are not represented as maps. While they will appear
empty when viewed as maps, the specific import namespace keys will still be
accessible.

-> Note that while current versions of HCP Terraform source configuration and
state data from the plan for the Terraform run in question, future versions may
source data accessed through the `tfconfig` and `tfstate` imports (as opposed to
`tfplan.config` and `tfplan.state`) from actual config bundles, or state as
stored by HCP Terraform. When this happens, the distinction here will be useful -
the data in the aliased namespaces will be the config and state data as the
_plan_ sees it, versus the actual "physical" data.

### Function: `module()`

```
module = func(ADDR)
```

* **Return Type:** A [module namespace](#namespace-module).

The `module()` function in the [root namespace](#namespace-root) returns the
[module namespace](#namespace-module) for a particular module address.

The address must be a list and is the module address, split on the period (`.`),
excluding the root module.

Hence, a module with an address of simply `foo` (or `root.foo`) would be
`["foo"]`, and a module within that (so address `foo.bar`) would be read as
`["foo", "bar"]`.

[`null`][ref-null] is returned if a module address is invalid, or if the module
is not present in the diff.

[ref-null]: https://docs.hashicorp.com/sentinel/language/spec#null

As an example, given the following module block:

```hcl
module "foo" {
  # ...
}
```

If the module contained the following content:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true`:

```python
import "tfplan"

main = rule { tfplan.module(["foo"]).resources.null_resource.foo[0].applied.triggers.foo is "bar" }
```

### Value: `module_paths`

* **Value Type:** List of a list of strings.

The `module_paths` value within the [root namespace](#namespace-root) is a list
of all of the modules within the Terraform diff for the current plan.

Modules not present in the diff will not be present here, even if they are
present in the configuration or state.

This data is represented as a list of a list of strings, with the inner list
being the module address, split on the period (`.`).

The root module is included in this list, represented as an empty inner list, as
long as there are changes.

As an example, if the following module block was present within a Terraform
configuration:

```hcl
module "foo" {
  # ...
}
```

The value of `module_paths` would be:

```
[
	[],
	["foo"],
]
```

And the following policy would evaluate to `true`:

```python
import "tfplan"

main = rule { tfplan.module_paths contains ["foo"] }
```

-> Note the above example only applies if the module is present in the diff.

#### Iterating Through Modules

Iterating through all modules to find particular resources can be useful. This
[example][iterate-over-modules] shows how to use `module_paths` with the
[`module()` function](#function-module-) to find all resources of a
particular type from all modules that have pending changes using the `tfplan`
import.

[iterate-over-modules]: /terraform/cloud-docs/policy-enforcement/sentinel#sentinel-imports

### Value: `terraform_version`

* **Value Type:** String.

The `terraform_version` value within the [root namespace](#namespace-root)
represents the version of Terraform used to create the plan. This can be used to
enforce a specific version of Terraform in a policy check.

As an example, the following policy would evaluate to `true`, as long as the
plan was made with a version of Terraform in the 0.11.x series, excluding any
pre-release versions (example: `-beta1` or `-rc1`):

```python
import "tfplan"

main = rule { tfplan.terraform_version matches "^0\\.11\\.\\d+$" }
```

### Value: `variables`

* **Value Type:** A string-keyed map of values.

The `variables` value within the [root namespace](#namespace-root) represents
all of the variables that were set when creating the plan. This will only
contain variables set for the root module.

Note that unlike the [`default`][import-tfconfig-variables-default] value in the
[`tfconfig` variables namespace][import-tfconfig-variables], primitive values
here are stringified, and type conversion will need to be performed to perform
comparison for int, float, or boolean values. This only applies to variables
that are primitives themselves and not primitives within maps and lists, which
will be their original types.

[import-tfconfig-variables-default]: /terraform/cloud-docs/policy-enforcement/sentinel/import/tfconfig#value-default

[import-tfconfig-variables]: /terraform/cloud-docs/policy-enforcement/sentinel/import/tfconfig#namespace-variables

If a default was accepted for the particular variable, the default value will be
populated here.

As an example, given the following variable blocks:

```hcl
variable "foo" {
  default = "bar"
}

variable "number" {
  default = 42
}

variable "map" {
  default = {
    foo    = "bar"
    number = 42
  }
}
```

The following policy would evaluate to `true`, if no values were entered to
change these variables:

```python
import "tfplan"

default_foo = rule { tfplan.variables.foo is "bar" }
default_number = rule { tfplan.variables.number is "42" }
default_map_string = rule { tfplan.variables.map["foo"] is "bar" }
default_map_int = rule { tfplan.variables.map["number"] is 42 }

main = rule { default_foo and default_number and default_map_string and default_map_int }
```

## Namespace: Module

The **module namespace** can be loaded by calling
[`module()`](#function-module-) for a particular module.

It can be used to load the following child namespaces, in addition to the values
documented below:

* `data` - Loads the [resource namespace](#namespace-resources-data-sources),
  filtered against data sources.
* `resources` - Loads the [resource
  namespace](#namespace-resources-data-sources), filtered against resources.

### Root Namespace Aliases

The root-level `data` and `resources` keys both alias to their corresponding
namespaces within the module namespace, loaded for the root module. They are the
equivalent of running `module([]).KEY`.

### Value: `path`

* **Value Type:** List of strings.

The `path` value within the [module namespace](#namespace-module) contains the
path of the module that the namespace represents. This is represented as a list
of strings.

As an example, if the following module block was present within a Terraform
configuration:

```hcl
module "foo" {
  # ...
}
```

The following policy would evaluate to `true` _only_ if the diff had changes for
that module:

```python
import "tfplan"

main = rule { tfplan.module(["foo"]).path contains "foo" }
```

## Namespace: Resources/Data Sources

The **resource namespace** is a namespace _type_ that applies to both resources
(accessed by using the `resources` namespace key) and data sources (accessed
using the `data` namespace key).

Accessing an individual resource or data source within each respective namespace
can be accomplished by specifying the type, name, and resource number (as if the
resource or data source had a `count` value in it) in the syntax
`[resources|data].TYPE.NAME[NUMBER]`. Note that NUMBER is always needed, even if
you did not use `count` in the resource.

In addition, each of these namespace levels is a map, allowing you to filter
based on type and name.

-> The (somewhat strange) notation here of `TYPE.NAME[NUMBER]` may imply that
the inner resource index map is actually a list, but it's not - using the square
bracket notation over the dotted notation (`TYPE.NAME.NUMBER`) is required here
as an identifier cannot start with a number.

Some examples of multi-level access are below:

* To fetch all `aws_instance.foo` resource instances within the root module, you
  can specify `tfplan.resources.aws_instance.foo`. This would then be indexed by
  resource count index (`0`, `1`, `2`, and so on). Note that as mentioned above,
  these elements must be accessed using square-bracket map notation (so `[0]`,
  `[1]`, `[2]`, and so on) instead of dotted notation.
* To fetch all `aws_instance` resources within the root module, you can specify
  `tfplan.resources.aws_instance`. This would be indexed from the names of
  each resource (`foo`, `bar`, and so on), with each of those maps containing
  instances indexed by resource count index as per above.
* To fetch all resources within the root module, irrespective of type, use
  `tfplan.resources`. This is indexed by type, as shown above with
  `tfplan.resources.aws_instance`, with names being the next level down, and so
  on.

~> When [resource targeting](/terraform/cli/commands/plan#resource-targeting) is in effect, `tfplan.resources` will only include the resources specified as targets for the run. This may lead to unexpected outcomes if a policy expects a resource to be present in the plan. To prohibit targeted runs altogether, ensure [`tfrun.target_addrs`](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfrun#value-target_addrs) is undefined or empty.

Further explanation of the namespace will be in the context of resources. As
mentioned, when operating on data sources, use the same syntax, except with
`data` in place of `resources`.

### Value: `applied`

* **Value Type:** A string-keyed map of values.

The `applied` value within the [resource
namespace](#namespace-resources-data-sources) contains a "predicted"
representation of the resource's state post-apply. It's created by merging the
pending resource's diff on top of the existing data from the resource's state
(if any). The map is a complex representation of these values with data going
as far down as needed to represent any state values such as maps, lists, and
sets.

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true` if the resource was in the diff:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.foo[0].applied.triggers.foo is "bar" }
```

-> Note that some values will not be available in the `applied` state because
they cannot be known until the plan is actually applied. In Terraform 0.11 or
earlier, these values are represented by a placeholder (the UUID value
`74D93920-ED26-11E3-AC10-0800200C9A66`) and in Terraform 0.12 or later they
are `undefined`. **In either case**, you should instead use the
[`computed`](#value-computed) key within the [diff
namespace](#namespace-resource-diff) to determine that a computed value will
exist.

-> If a resource is being destroyed, its `applied` value is omitted from the
namespace and trying to fetch it will return undefined.

### Value: `diff`

* **Value Type:** A map of [diff namespaces](#namespace-resource-diff).

The `diff` value within the [resource
namespace](#namespace-resources-data-sources) contains the diff for a particular
resource. Each key within the map links to a [diff
namespace](#namespace-resource-diff) for that particular key.

Note that unlike the [`applied`](#value-applied) value, this map is not complex;
the map is only 1 level deep with each key possibly representing a diff for a
particular complex value within the resource.

See the below section for more details on the diff namespace, in addition to
usage examples.

### Value: `destroy`

* **Value Type:** Boolean.

The `destroy` value within the [resource
namespace](#namespace-resources-data-sources) is `true` if a resource is being
destroyed for _any_ reason, including cases where it's being deleted as part of
a resource re-creation, in which case [`requires_new`](#value-requires_new) will
also be set.

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true` when `null_resource.foo` is being
destroyed:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.foo[0].destroy }
```

### Value: `requires_new`

* **Value Type:** Boolean.

The `requires_new` value within the [resource
namespace](#namespace-resources-data-sources) is `true` if the resource is still
present in the configuration, but must be replaced to satisfy its current diff.
Whenever `requires_new` is `true`, [`destroy`](#value-destroy) is also `true`.

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true` if one of the `triggers` in
`null_resource.foo` was being changed:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.foo[0].requires_new }
```

## Namespace: Resource Diff

The **diff namespace** is a namespace that represents the diff for a specific
attribute within a resource. For details on reading a particular attribute,
see the [`diff`](#value-diff) value in the [resource
namespace](#namespace-resources-data-sources).

### Value: `computed`

* **Value Type:** Boolean.

The `computed` value within the [diff namespace](#namespace-resource-diff) is
`true` if the resource key in question depends on another value that isn't yet
known. Typically, that means the value it depends on belongs to a resource that
either doesn't exist yet, or is changing state in such a way as to affect the
dependent value so that it can't be known until the apply is complete.

-> Keep in mind that when using `computed` with complex structures such as maps,
lists, and sets, it's sometimes necessary to test the count attribute for the
structure, versus a key within it, depending on whether or not the diff has
marked the whole structure as computed. This is demonstrated in the example
below.  Count keys are `%` for maps, and `#` for lists and sets. If you are
having trouble determining the type of specific field within a resource, contact
the support team.

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}

resource "null_resource" "bar" {
  triggers = {
    foo_id = "${null_resource.foo.id}"
  }
}
```

The following policy would evaluate to `true`, if the `id` of
`null_resource.foo` was currently not known, such as when the resource is
pending creation, or is being deleted and re-created:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.bar[0].diff["triggers.%"].computed }
```

### Value: `new`

* **Value Type:** String.

The `new` value within the [diff namespace](#namespace-resource-diff) contains
the new value of a changing attribute, _if_ the value is known at plan time.

-> `new` will be an empty string if the attribute's value is currently unknown.
For more details on detecting unknown values, see [`computed`](#value-computed).

Note that this value is _always_ a string, regardless of the actual type of the
value changing. [Type conversion][ref-sentinel-type-conversion] within policy
may be necessary to achieve the comparison needed.

[ref-sentinel-type-conversion]: https://docs.hashicorp.com/sentinel/language/values#type-conversion

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true`, if the resource was in the diff
and each of the concerned keys were changing to new values:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.foo[0].diff["triggers.foo"].new is "bar" }
```

### Value: `old`

* **Value Type:** String.

The `old` value within the [diff namespace](#namespace-resource-diff) contains
the old value of a changing attribute.

Note that this value is _always_ a string, regardless of the actual type of the
value changing. [Type conversion][ref-sentinel-type-conversion] within policy
may be necessary to achieve the comparison needed.

If the value did not exist in the previous state, `old` will always be an empty
string.

As an example, given the following resource:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "baz"
  }
}
```

If that resource was previously in config as:

```hcl
resource "null_resource" "foo" {
  triggers = {
    foo = "bar"
  }
}
```

The following policy would evaluate to `true`:

```python
import "tfplan"

main = rule { tfplan.resources.null_resource.foo[0].diff["triggers.foo"].old is "bar" }
```

page title  tfplan   Imports   Sentinel   HCP Terraform description       The tfplan import provides access to a Terraform plan  A Terraform plan is the   file created as a result of  terraform plan  and is the input to  terraform   apply   The plan represents the changes that Terraform needs to make to   infrastructure to reach the desired state represented by the configuration         Import  tfplan       Warning    The  tfplan  import is now deprecated and will be permanently removed in August 2025  We recommend that you start using the updated  tfplan v2   terraform cloud docs policy enforcement sentinel import tfplan v2  import as soon as possible to avoid disruptions  The  tfplan v2  import offers improved functionality and is designed to better support your policy enforcement needs   The  tfplan  import provides access to a Terraform plan  A Terraform plan is the file created as a result of  terraform plan  and is the input to  terraform apply   The plan represents the changes that Terraform needs to make to infrastructure to reach the desired state represented by the configuration   In addition to the diff data available in the plan  there is an   applied    value applied  state available that merges the plan with the state to create the planned state after apply   Finally  this import also allows you to access the configuration files and the Terraform state at the time the plan was run  See the section on  accessing a plan s state and configuration data   accessing a plan 39 s state and configuration data  for more information        BEGIN  TFC only name pnp callout      include  tfc package callouts policies mdx       END  TFC only name pnp callout         Namespace Overview  The following is a tree view of the import namespace  For more detail on a particular part of the namespace  see below      Note that the root level alias keys shown here   data    path   and  resources   are shortcuts to a  module namespace   namespace module  scoped to the root module  For more details  see the section on  root namespace aliases   root namespace aliases        tfplan     module    function           module namespace              path    string              data                 TYPE NAME NUMBER                      applied  map of keys                      diff                         KEY                             computed  bool                              new  string                              old  string              resources                 TYPE NAME NUMBER                      applied  map of keys                      destroy  bool                      requires new  bool                      diff                         KEY                             computed  bool                              new  string                              old  string      module paths      string      terraform version  string      variables  map of keys        data  root module alias      path  root module alias      resources  root module alias        config  tfconfig namespace alias      state  tfstate import alias          Namespace  Root  The root level namespace consists of the values and functions documented below   In addition to this  the root level  data    path   and  resources  keys alias to their corresponding namespaces or values within the  module namespace   namespace module        Accessing a Plan s State and Configuration Data  The  config  and  state  keys alias to the   tfconfig   import tfconfig  and   tfstate   import tfstate  namespaces  respectively  with the data sourced from the Terraform  plan   as opposed to actual configuration and state     import tfconfig    terraform cloud docs policy enforcement sentinel import tfconfig   import tfstate    terraform cloud docs policy enforcement sentinel import tfstate     Note that these aliases are not represented as maps  While they will appear empty when viewed as maps  the specific import namespace keys will still be accessible      Note that while current versions of HCP Terraform source configuration and state data from the plan for the Terraform run in question  future versions may source data accessed through the  tfconfig  and  tfstate  imports  as opposed to  tfplan config  and  tfplan state   from actual config bundles  or state as stored by HCP Terraform  When this happens  the distinction here will be useful   the data in the aliased namespaces will be the config and state data as the  plan  sees it  versus the actual  physical  data       Function   module         module   func ADDR           Return Type    A  module namespace   namespace module    The  module    function in the  root namespace   namespace root  returns the  module namespace   namespace module  for a particular module address   The address must be a list and is the module address  split on the period        excluding the root module   Hence  a module with an address of simply  foo   or  root foo   would be    foo     and a module within that  so address  foo bar   would be read as    foo    bar        null   ref null  is returned if a module address is invalid  or if the module is not present in the diff    ref null   https   docs hashicorp com sentinel language spec null  As an example  given the following module block      hcl module  foo                   If the module contained the following content      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true       python import  tfplan   main   rule   tfplan module   foo    resources null resource foo 0  applied triggers foo is  bar             Value   module paths       Value Type    List of a list of strings   The  module paths  value within the  root namespace   namespace root  is a list of all of the modules within the Terraform diff for the current plan   Modules not present in the diff will not be present here  even if they are present in the configuration or state   This data is represented as a list of a list of strings  with the inner list being the module address  split on the period         The root module is included in this list  represented as an empty inner list  as long as there are changes   As an example  if the following module block was present within a Terraform configuration      hcl module  foo                   The value of  module paths  would be                 foo           And the following policy would evaluate to  true       python import  tfplan   main   rule   tfplan module paths contains   foo             Note the above example only applies if the module is present in the diff        Iterating Through Modules  Iterating through all modules to find particular resources can be useful  This  example  iterate over modules  shows how to use  module paths  with the   module    function   function module   to find all resources of a particular type from all modules that have pending changes using the  tfplan  import    iterate over modules    terraform cloud docs policy enforcement sentinel sentinel imports      Value   terraform version       Value Type    String   The  terraform version  value within the  root namespace   namespace root  represents the version of Terraform used to create the plan  This can be used to enforce a specific version of Terraform in a policy check   As an example  the following policy would evaluate to  true   as long as the plan was made with a version of Terraform in the 0 11 x series  excluding any pre release versions  example    beta1  or   rc1        python import  tfplan   main   rule   tfplan terraform version matches   0   11     d               Value   variables       Value Type    A string keyed map of values   The  variables  value within the  root namespace   namespace root  represents all of the variables that were set when creating the plan  This will only contain variables set for the root module   Note that unlike the   default   import tfconfig variables default  value in the   tfconfig  variables namespace  import tfconfig variables   primitive values here are stringified  and type conversion will need to be performed to perform comparison for int  float  or boolean values  This only applies to variables that are primitives themselves and not primitives within maps and lists  which will be their original types    import tfconfig variables default    terraform cloud docs policy enforcement sentinel import tfconfig value default   import tfconfig variables    terraform cloud docs policy enforcement sentinel import tfconfig namespace variables  If a default was accepted for the particular variable  the default value will be populated here   As an example  given the following variable blocks      hcl variable  foo      default    bar     variable  number      default   42    variable  map      default         foo       bar      number   42            The following policy would evaluate to  true   if no values were entered to change these variables      python import  tfplan   default foo   rule   tfplan variables foo is  bar    default number   rule   tfplan variables number is  42    default map string   rule   tfplan variables map  foo   is  bar    default map int   rule   tfplan variables map  number   is 42    main   rule   default foo and default number and default map string and default map int           Namespace  Module  The   module namespace   can be loaded by calling   module      function module   for a particular module   It can be used to load the following child namespaces  in addition to the values documented below      data    Loads the  resource namespace   namespace resources data sources     filtered against data sources     resources    Loads the  resource   namespace   namespace resources data sources   filtered against resources       Root Namespace Aliases  The root level  data  and  resources  keys both alias to their corresponding namespaces within the module namespace  loaded for the root module  They are the equivalent of running  module     KEY        Value   path       Value Type    List of strings   The  path  value within the  module namespace   namespace module  contains the path of the module that the namespace represents  This is represented as a list of strings   As an example  if the following module block was present within a Terraform configuration      hcl module  foo                   The following policy would evaluate to  true   only  if the diff had changes for that module      python import  tfplan   main   rule   tfplan module   foo    path contains  foo            Namespace  Resources Data Sources  The   resource namespace   is a namespace  type  that applies to both resources  accessed by using the  resources  namespace key  and data sources  accessed using the  data  namespace key    Accessing an individual resource or data source within each respective namespace can be accomplished by specifying the type  name  and resource number  as if the resource or data source had a  count  value in it  in the syntax   resources data  TYPE NAME NUMBER    Note that NUMBER is always needed  even if you did not use  count  in the resource   In addition  each of these namespace levels is a map  allowing you to filter based on type and name      The  somewhat strange  notation here of  TYPE NAME NUMBER   may imply that the inner resource index map is actually a list  but it s not   using the square bracket notation over the dotted notation   TYPE NAME NUMBER   is required here as an identifier cannot start with a number   Some examples of multi level access are below     To fetch all  aws instance foo  resource instances within the root module  you   can specify  tfplan resources aws instance foo   This would then be indexed by   resource count index   0    1    2   and so on   Note that as mentioned above    these elements must be accessed using square bracket map notation  so   0        1      2    and so on  instead of dotted notation    To fetch all  aws instance  resources within the root module  you can specify    tfplan resources aws instance   This would be indexed from the names of   each resource   foo    bar   and so on   with each of those maps containing   instances indexed by resource count index as per above    To fetch all resources within the root module  irrespective of type  use    tfplan resources   This is indexed by type  as shown above with    tfplan resources aws instance   with names being the next level down  and so   on      When  resource targeting   terraform cli commands plan resource targeting  is in effect   tfplan resources  will only include the resources specified as targets for the run  This may lead to unexpected outcomes if a policy expects a resource to be present in the plan  To prohibit targeted runs altogether  ensure   tfrun target addrs    terraform cloud docs policy enforcement sentinel import tfrun value target addrs  is undefined or empty   Further explanation of the namespace will be in the context of resources  As mentioned  when operating on data sources  use the same syntax  except with  data  in place of  resources        Value   applied       Value Type    A string keyed map of values   The  applied  value within the  resource namespace   namespace resources data sources  contains a  predicted  representation of the resource s state post apply  It s created by merging the pending resource s diff on top of the existing data from the resource s state  if any   The map is a complex representation of these values with data going as far down as needed to represent any state values such as maps  lists  and sets   As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true  if the resource was in the diff      python import  tfplan   main   rule   tfplan resources null resource foo 0  applied triggers foo is  bar            Note that some values will not be available in the  applied  state because they cannot be known until the plan is actually applied  In Terraform 0 11 or earlier  these values are represented by a placeholder  the UUID value  74D93920 ED26 11E3 AC10 0800200C9A66   and in Terraform 0 12 or later they are  undefined     In either case    you should instead use the   computed    value computed  key within the  diff namespace   namespace resource diff  to determine that a computed value will exist      If a resource is being destroyed  its  applied  value is omitted from the namespace and trying to fetch it will return undefined       Value   diff       Value Type    A map of  diff namespaces   namespace resource diff    The  diff  value within the  resource namespace   namespace resources data sources  contains the diff for a particular resource  Each key within the map links to a  diff namespace   namespace resource diff  for that particular key   Note that unlike the   applied    value applied  value  this map is not complex  the map is only 1 level deep with each key possibly representing a diff for a particular complex value within the resource   See the below section for more details on the diff namespace  in addition to usage examples       Value   destroy       Value Type    Boolean   The  destroy  value within the  resource namespace   namespace resources data sources  is  true  if a resource is being destroyed for  any  reason  including cases where it s being deleted as part of a resource re creation  in which case   requires new    value requires new  will also be set   As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true  when  null resource foo  is being destroyed      python import  tfplan   main   rule   tfplan resources null resource foo 0  destroy            Value   requires new       Value Type    Boolean   The  requires new  value within the  resource namespace   namespace resources data sources  is  true  if the resource is still present in the configuration  but must be replaced to satisfy its current diff  Whenever  requires new  is  true     destroy    value destroy  is also  true    As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true  if one of the  triggers  in  null resource foo  was being changed      python import  tfplan   main   rule   tfplan resources null resource foo 0  requires new           Namespace  Resource Diff  The   diff namespace   is a namespace that represents the diff for a specific attribute within a resource  For details on reading a particular attribute  see the   diff    value diff  value in the  resource namespace   namespace resources data sources        Value   computed       Value Type    Boolean   The  computed  value within the  diff namespace   namespace resource diff  is  true  if the resource key in question depends on another value that isn t yet known  Typically  that means the value it depends on belongs to a resource that either doesn t exist yet  or is changing state in such a way as to affect the dependent value so that it can t be known until the apply is complete      Keep in mind that when using  computed  with complex structures such as maps  lists  and sets  it s sometimes necessary to test the count attribute for the structure  versus a key within it  depending on whether or not the diff has marked the whole structure as computed  This is demonstrated in the example below   Count keys are     for maps  and     for lists and sets  If you are having trouble determining the type of specific field within a resource  contact the support team   As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    bar         resource  null resource   bar      triggers         foo id      null resource foo id              The following policy would evaluate to  true   if the  id  of  null resource foo  was currently not known  such as when the resource is pending creation  or is being deleted and re created      python import  tfplan   main   rule   tfplan resources null resource bar 0  diff  triggers     computed            Value   new       Value Type    String   The  new  value within the  diff namespace   namespace resource diff  contains the new value of a changing attribute   if  the value is known at plan time       new  will be an empty string if the attribute s value is currently unknown  For more details on detecting unknown values  see   computed    value computed    Note that this value is  always  a string  regardless of the actual type of the value changing   Type conversion  ref sentinel type conversion  within policy may be necessary to achieve the comparison needed    ref sentinel type conversion   https   docs hashicorp com sentinel language values type conversion  As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true   if the resource was in the diff and each of the concerned keys were changing to new values      python import  tfplan   main   rule   tfplan resources null resource foo 0  diff  triggers foo   new is  bar             Value   old       Value Type    String   The  old  value within the  diff namespace   namespace resource diff  contains the old value of a changing attribute   Note that this value is  always  a string  regardless of the actual type of the value changing   Type conversion  ref sentinel type conversion  within policy may be necessary to achieve the comparison needed   If the value did not exist in the previous state   old  will always be an empty string   As an example  given the following resource      hcl resource  null resource   foo      triggers         foo    baz             If that resource was previously in config as      hcl resource  null resource   foo      triggers         foo    bar             The following policy would evaluate to  true       python import  tfplan   main   rule   tfplan resources null resource foo 0  diff  triggers foo   old is  bar


terraform Note This is documentation for the next version of the tfconfig Sentinel import designed specifically for Terraform 0 12 This import requires page title tfconfig v2 Imports Sentinel HCP Terraform example import tfconfig v2 as tfconfig The tfconfig v2 import provides access to a Terraform configuration Terraform 0 12 or higher and must currently be loaded by path using an alias

Answer:
---
page_title: tfconfig/v2 - Imports - Sentinel - HCP Terraform
description: The tfconfig/v2 import provides access to a Terraform configuration.
---

-> **Note:** This is documentation for the next version of the `tfconfig`
Sentinel import, designed specifically for Terraform 0.12. This import requires
Terraform 0.12 or higher, and must currently be loaded by path, using an alias,
example: `import "tfconfig/v2" as tfconfig`.

# Import: tfconfig/v2

The `tfconfig/v2` import provides access to a Terraform configuration.

The Terraform configuration is the set of `*.tf` files that are used to
describe the desired infrastructure state. Policies using the `tfconfig`
import can access all aspects of the configuration: providers, resources,
data sources, modules, and variables.

<!-- BEGIN: TFC:only name:pnp-callout -->
@include 'tfc-package-callouts/policies.mdx'
<!-- END: TFC:only name:pnp-callout -->

Some use cases for `tfconfig` include:

* **Organizational naming conventions**: requiring that configuration elements
  are named in a way that conforms to some organization-wide standard.
* **Required inputs and outputs**: organizations may require a particular set
  of input variable names across all workspaces or may require a particular
  set of outputs for asset management purposes.
* **Enforcing particular modules**: organizations may provide a number of
  "building block" modules and require that each workspace be built only from
  combinations of these modules.
* **Enforcing particular providers or resources**: an organization may wish to
  require or prevent the use of providers and/or resources so that configuration
  authors cannot use alternative approaches to work around policy
  restrictions.

The data in the `tfconfig/v2` import is sourced from the JSON configuration file
that is generated by the [`terraform show -json`](/terraform/cli/commands/show#json-output) command. For more information on
the file format, see the [JSON Output Format](/terraform/internals/json-format)
page.

## Import Overview

The `tfconfig/v2` import is structured as a series of _collections_, keyed as a
specific format, such as resource address, module address, or a
specifically-formatted provider key.

```
tfconfig/v2
├── strip_index() (function)
├── providers
│   └── (indexed by [module_address:]provider[.alias])
│       ├── provider_config_key (string)
│       ├── name (string)
│       ├── full_name (string)
│       ├── alias (string)
│       ├── module_address (string)
│       ├── config (block expression representation)
│       └── version_constraint (string)
├── resources
│   └── (indexed by address)
│       ├── address (string)
│       ├── module_address (string)
│       ├── mode (string)
│       ├── type (string)
│       ├── name (string)
│       ├── provider_config_key (string)
│       ├── provisioners (list)
│       │   └── (ordered provisioners for this resource only)
│       ├── config (block expression representation)
│       ├── count (expression representation)
│       ├── for_each (expression representation)
│       └── depends_on (list of strings)
├── provisioners
│   └── (indexed by resource_address:index)
│       ├── resource_address (string)
│       ├── type (string)
│       ├── index (string)
│       └── config (block expression representation)
├── variables
│   └── (indexed by module_address:name)
│       ├── module_address (string)
│       ├── name (string)
│       ├── default (value)
│       └── description (string)
├── outputs
│   └── (indexed by module_address:name)
│       ├── module_address (string)
│       ├── name (string)
│       ├── sensitive (boolean)
│       ├── value (expression representation)
│       ├── description (string)
│       └── depends_on (list of strings)
└── module_calls
    └── (indexed by module_address:name)
        ├── module_address (string)
        ├── name (string)
        ├── source (string)
        ├── config (block expression representation)
        ├── count (expression representation)
        ├── depends_on (expression representation)
        ├── for_each (expression representation)
        └── version_constraint (string)
```

The collections are:

* [`providers`](#the-providers-collection) - The configuration for all provider
  instances across all modules in the configuration.
* [`resources`](#the-resources-collection) - The configuration of all resources
  across all modules in the configuration.
* [`variables`](#the-variables-collection) - The configuration of all variable
  definitions across all modules in the configuration.
* [`outputs`](#the-outputs-collection) - The configuration of all output
  definitions across all modules in the configuration.
* [`module_calls`](#the-module_calls-collection) - The configuration of all module
  calls (individual [`module`](/terraform/language/modules) blocks) across
  all modules in the configuration.

These collections are specifically designed to be used with the
[`filter`](https://docs.hashicorp.com/sentinel/language/collection-operations#filter-expression)
quantifier expression in Sentinel, so that one can collect a list of resources
to perform policy checks on without having to write complex module or
configuration traversal. As an example, the following code will return all
`aws_instance` resource types within the configuration, regardless of what
module they are in:

```
all_aws_instances = filter tfconfig.resources as _, r {
	r.mode is "managed" and
		r.type is "aws_instance"
}
```

You can add specific attributes to the filter to narrow the search, such as the
module address. The following code would return resources in a module named
`foo` only:

```
all_aws_instances = filter tfconfig.resources as _, r {
	r.module_address is "module.foo" and
		r.mode is "managed" and
		r.type is "aws_instance"
}
```

### Address Differences Between `tfconfig`, `tfplan`, and `tfstate`

This import deals with configuration before it is expanded into a
resource graph by Terraform. As such, it is not possible to compute an index as
the import is building its collections and computing addresses for resources and
modules.

As such, addresses found here may not always match the expanded addresses found
in the [`tfplan/v2`](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfplan-v2) and [`tfstate/v2`](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfstate-v2)
imports, specifically when
[`count`](/terraform/language/resources#count-multiple-resource-instances-by-count)
and
[`for_each`](/terraform/language/resources#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings),
are used.

As an example, consider a resource named `null_resource.foo` with a count of `2`
located in a module named `bar`. While there will possibly be entries in the
other imports for `module.bar.null_resource.foo[0]` and
`module.bar.null_resource.foo[1]`, in `tfconfig/v2`, there will only be a
`module.bar.null_resource.foo`. As mentioned in the start of this section, this
is because configuration actually _defines_ this scaling, whereas _expansion_
actually happens when the resource graph is built, which happens as a natural
part of the refresh and planning process.

The `strip_index` helper function, found in this import, can assist in
removing the indexes from addresses found in the `tfplan/v2` and `tfstate/v2`
imports so that data from those imports can be used to reference data in this
one.

## The `strip_index` Function

The `strip_index` helper function can be used to remove indexes from addresses
found in [`tfplan/v2`](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfplan-v2) and [`tfstate/v2`](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfstate-v2),
by removing the indexes from each resource.

This can be used to help facilitate cross-import lookups for data between plan,
state, and config.

```
import "tfconfig/v2" as tfconfig
import "tfplan/v2" as tfplan

main = rule {
	all filter tfplan.resource_changes as _, rc {
		rc.mode is "managed" and
			rc.type is "aws_instance"
	} as _, rc {
		tfconfig.resources[tfconfig.strip_index(rc.address)].config.ami.constant_value is "ami-abcdefgh012345"
	}
}
```

## Expression Representations

Most collections in this import will have one of two kinds of _expression
representations_. This is a verbose format for expressing a (parsed)
configuration value independent of the configuration source code, which is not
100% available to a policy check in HCP Terraform.

```
(expression representation)
├── constant_value (value)
└── references (list of strings)
```

There are two major parts to an expression representation:

* Any _strictly constant value_ is expressed as an expression with a
  `constant_value` field.
* Any expression that requires some degree of evaluation to generate the final
  value - even if that value is known at plan time - is not expressed in
  configuration. Instead, any particular references that are made are added to
  the `references` field. More details on this field can be found in the
  [expression
  representation](/terraform/internals/json-format#expression-representation)
  section of the JSON output format documentation.

For example, to determine if an output is based on a particular
resource value, one could do:

```
import "tfconfig/v2" as tfconfig

main = rule {
	tfconfig.outputs["instance_id"].value.references is ["aws_instance.foo"]
}
```

-> **Note:** The representation does not account for
complex interpolations or other expressions that combine constants with other
expression data. For example, the partially constant data in `"foo${var.bar}"` would be lost.

### Block Expression Representation

Expanding on the above, a multi-value expression representation (such as the
kind found in a [`resources`](#the-resources-collection) collection element) is
similar, but the root value is a keyed map of expression representations. This
is repeated until a "scalar" expression value is encountered, ie: a field that
is not a block in the resource's schema.

```
(block expression representation)
└── (attribute key)
    ├── (child block expression representation)
    │   └── (...)
    ├── constant_value (value)
    └── references (list of strings)
```

As an example, one can validate expressions in an
[`aws_instance`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance) resource using the
following:

```
import "tfconfig/v2" as tfconfig

main = rule {
	tfconfig.resources["aws_instance.foo"].config.ami.constant_value is "ami-abcdefgh012345"
}
```

Note that _nested blocks_, sometimes known as _sub-resources_, will be nested in
configuration as a list of blocks (reflecting their ultimate nature as a list
of objects). An example would be the `aws_instance` resource's
[`ebs_block_device`](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#ebs-ephemeral-and-root-block-devices) block:

```
import "tfconfig/v2" as tfconfig

main = rule {
	tfconfig.resources["aws_instance.foo"].config.ebs_block_device[0].volume_size < 10
}
```

## The `providers` Collection

The `providers` collection is a collection representing the configurations of
all provider instances across all modules in the configuration.

This collection is indexed by an opaque key. This is currently
`module_address:provider.alias`, the same value as found in the
`provider_config_key` field. `module_address` and the colon delimiter are
omitted for the root module.

The `provider_config_key` field is also found in the `resources` collection and
can be used to locate a provider that belongs to a configured resource.

The fields in this collection are as follows:

* `provider_config_key` - The opaque configuration key, used as the index key.
* `name` - The name of the provider, ie: `aws`.
* `full_name` - The fully-qualified name of the provider, e.g. `registry.terraform.io/hashicorp/aws`.
* `alias` - The alias of the provider, ie: `east`. Empty for a default provider.
* `module_address` - The address of the module this provider appears in.
* `config` - A [block expression
  representation](#block-expression-representation) with provider configuration
  values.
* `version_constraint` - The defined version constraint for this provider.

## The `resources` Collection

The `resources` collection is a collection representing all of the resources
found in all modules in the configuration.

This collection is indexed by the resource address.

The fields in this collection are as follows:

* `address` - The resource address. This is the index of the collection.
* `module_address` - The module address that this resource was found in.
* `mode` - The resource mode, either `managed` (resources) or `data` (data
  sources).
* `type` - The type of resource, ie: `null_resource` in `null_resource.foo`.
* `name` - The name of the resource, ie: `foo` in `null_resource.foo`.
* `provider_config_key` - The opaque configuration key that serves as the index
  of the [`providers`](#the-providers-collection) collection.
* `provisioners` - The ordered list of provisioners for this resource. The
  syntax of the provisioners matches those found in the
  [`provisioners`](#the-provisioners-collection) collection, but is a list
  indexed by the order the provisioners show up in the resource.
* `config` - The [block expression
  representation](#block-expression-representation) of the configuration values
  found in the resource.
* `count` - The [expression data](#expression-representations) for the `count`
  value in the resource.
* `for_each` - The [expression data](#expression-representations) for the
  `for_each` value in the resource.
* `depends_on` - The contents of the `depends_on` config directive, which
  declares explicit dependencies for this resource.

## The `provisioners` Collection

The `provisioners` collection is a collection of all of the provisioners found
across all resources in the configuration.

While normally bound to a resource in an ordered fashion, this collection allows
for the filtering of provisioners within a single expression.

This collection is indexed with a key following the format
`resource_address:index`, with each field matching their respective field in the
particular element below:

* `resource_address`: The address of the resource that the provisioner was found
  in. This can be found in the [`resources`](#the-resources-collection)
  collection.
* `type`: The provisioner type, ie: `local_exec`.
* `index`: The provisioner index as it shows up in the resource provisioner
  order.
* `config`: The [block expression
  representation](#block-expression-representation) of the configuration values
  in the provisioner.

## The `variables` Collection

The `variables` collection is a collection of all variables across all modules
in the configuration.

Note that this tracks variable definitions, not values. See the [`tfplan/v2`
`variables` collection](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfplan-v2#the-variables-collection) for variable
values set within a plan.

This collection is indexed by the key format `module_address:name`, with each
field matching their respective name below. `module_address` and the colon
delimiter are omitted for the root module.

* `module_address` - The address of the module the variable was found in.
* `name` - The name of the variable.
* `default` - The defined default value of the variable.
* `description` - The description of the variable.

## The `outputs` Collection

The `outputs` collection is a collection of all outputs across all modules in
the configuration.

Note that this tracks variable definitions, not values. See the [`tfstate/v2`
`outputs` collection](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfstate-v2#the-outputs-collection) for the final
values of outputs set within a state. The [`tfplan/v2` `output_changes`
collection](/terraform/cloud-docs/policy-enforcement/sentinel/import/tfplan-v2#the-output_changes-collection) also contains a more
complex collection of planned output changes.

This collection is indexed by the key format `module_address:name`, with each
field matching their respective name below. `module_address` and the colon
delimiter are omitted for the root module.

* `module_address` - The address of the module the output was found in.
* `name` - The name of the output.
* `sensitive` - Indicates whether or not the output was marked as
  [`sensitive`](/terraform/language/values/outputs#sensitive-suppressing-values-in-cli-output).
* `value` - An [expression representation](#expression-representations) for the output.
* `description` - The description of the output.
* `depends_on` - A list of resource names that the output depends on. These are
  the hard-defined output dependencies as defined in the
  [`depends_on`](/terraform/language/values/outputs#depends_on-explicit-output-dependencies)
  field in an output declaration, not the dependencies that get derived from
  natural evaluation of the output expression (these can be found in the
  `references` field of the expression representation).

## The `module_calls` Collection

The `module_calls` collection is a collection of all module declarations at all
levels within the configuration.

Note that this is the
[`module`](/terraform/language/modules#calling-a-child-module) stanza in
any particular configuration, and not the module itself. Hence, a declaration
for `module.foo` would actually be declared in the root module, which would be
represented by a blank field in `module_address`.

This collection is indexed by the key format `module_address:name`, with each
field matching their respective name below. `module_address` and the colon
delimiter are omitted for the root module.

* `module_address` - The address of the module the declaration was found in.
* `name` - The name of the module.
* `source` - The contents of the `source` field.
* `config` - A [block expression
  representation](#block-expression-representation) for all parameter values
  sent to the module.
* `count` - An [expression representation](#expression-representations) for the
  `count` field.
* `depends_on`: An [expression representation](#expression-representations) for the
  `depends_on` field.
* `for_each` - An [expression representation](#expression-representations) for
  the `for_each` field.
* `version_constraint` - The string value found in the `version` field of the
  module declaration.

page title  tfconfig v2   Imports   Sentinel   HCP Terraform description  The tfconfig v2 import provides access to a Terraform configuration            Note    This is documentation for the next version of the  tfconfig  Sentinel import  designed specifically for Terraform 0 12  This import requires Terraform 0 12 or higher  and must currently be loaded by path  using an alias  example   import  tfconfig v2  as tfconfig      Import  tfconfig v2  The  tfconfig v2  import provides access to a Terraform configuration   The Terraform configuration is the set of    tf  files that are used to describe the desired infrastructure state  Policies using the  tfconfig  import can access all aspects of the configuration  providers  resources  data sources  modules  and variables        BEGIN  TFC only name pnp callout      include  tfc package callouts policies mdx       END  TFC only name pnp callout      Some use cases for  tfconfig  include       Organizational naming conventions    requiring that configuration elements   are named in a way that conforms to some organization wide standard      Required inputs and outputs    organizations may require a particular set   of input variable names across all workspaces or may require a particular   set of outputs for asset management purposes      Enforcing particular modules    organizations may provide a number of    building block  modules and require that each workspace be built only from   combinations of these modules      Enforcing particular providers or resources    an organization may wish to   require or prevent the use of providers and or resources so that configuration   authors cannot use alternative approaches to work around policy   restrictions   The data in the  tfconfig v2  import is sourced from the JSON configuration file that is generated by the   terraform show  json    terraform cli commands show json output  command  For more information on the file format  see the  JSON Output Format   terraform internals json format  page      Import Overview  The  tfconfig v2  import is structured as a series of  collections   keyed as a specific format  such as resource address  module address  or a specifically formatted provider key       tfconfig v2     strip index    function      providers          indexed by  module address  provider  alias               provider config key  string              name  string              full name  string              alias  string              module address  string              config  block expression representation              version constraint  string      resources          indexed by address              address  string              module address  string              mode  string              type  string              name  string              provider config key  string              provisioners  list                   ordered provisioners for this resource only              config  block expression representation              count  expression representation              for each  expression representation              depends on  list of strings      provisioners          indexed by resource address index              resource address  string              type  string              index  string              config  block expression representation      variables          indexed by module address name              module address  string              name  string              default  value              description  string      outputs          indexed by module address name              module address  string              name  string              sensitive  boolean              value  expression representation              description  string              depends on  list of strings      module calls          indexed by module address name              module address  string              name  string              source  string              config  block expression representation              count  expression representation              depends on  expression representation              for each  expression representation              version constraint  string       The collections are       providers    the providers collection    The configuration for all provider   instances across all modules in the configuration      resources    the resources collection    The configuration of all resources   across all modules in the configuration      variables    the variables collection    The configuration of all variable   definitions across all modules in the configuration      outputs    the outputs collection    The configuration of all output   definitions across all modules in the configuration      module calls    the module calls collection    The configuration of all module   calls  individual   module    terraform language modules  blocks  across   all modules in the configuration   These collections are specifically designed to be used with the   filter   https   docs hashicorp com sentinel language collection operations filter expression  quantifier expression in Sentinel  so that one can collect a list of resources to perform policy checks on without having to write complex module or configuration traversal  As an example  the following code will return all  aws instance  resource types within the configuration  regardless of what module they are in       all aws instances   filter tfconfig resources as    r    r mode is  managed  and   r type is  aws instance         You can add specific attributes to the filter to narrow the search  such as the module address  The following code would return resources in a module named  foo  only       all aws instances   filter tfconfig resources as    r    r module address is  module foo  and   r mode is  managed  and   r type is  aws instance             Address Differences Between  tfconfig    tfplan   and  tfstate   This import deals with configuration before it is expanded into a resource graph by Terraform  As such  it is not possible to compute an index as the import is building its collections and computing addresses for resources and modules   As such  addresses found here may not always match the expanded addresses found in the   tfplan v2    terraform cloud docs policy enforcement sentinel import tfplan v2  and   tfstate v2    terraform cloud docs policy enforcement sentinel import tfstate v2  imports  specifically when   count    terraform language resources count multiple resource instances by count  and   for each    terraform language resources for each multiple resource instances defined by a map or set of strings   are used   As an example  consider a resource named  null resource foo  with a count of  2  located in a module named  bar   While there will possibly be entries in the other imports for  module bar null resource foo 0   and  module bar null resource foo 1    in  tfconfig v2   there will only be a  module bar null resource foo   As mentioned in the start of this section  this is because configuration actually  defines  this scaling  whereas  expansion  actually happens when the resource graph is built  which happens as a natural part of the refresh and planning process   The  strip index  helper function  found in this import  can assist in removing the indexes from addresses found in the  tfplan v2  and  tfstate v2  imports so that data from those imports can be used to reference data in this one      The  strip index  Function  The  strip index  helper function can be used to remove indexes from addresses found in   tfplan v2    terraform cloud docs policy enforcement sentinel import tfplan v2  and   tfstate v2    terraform cloud docs policy enforcement sentinel import tfstate v2   by removing the indexes from each resource   This can be used to help facilitate cross import lookups for data between plan  state  and config       import  tfconfig v2  as tfconfig import  tfplan v2  as tfplan  main   rule    all filter tfplan resource changes as    rc     rc mode is  managed  and    rc type is  aws instance     as    rc     tfconfig resources tfconfig strip index rc address   config ami constant value is  ami abcdefgh012345               Expression Representations  Most collections in this import will have one of two kinds of  expression representations   This is a verbose format for expressing a  parsed  configuration value independent of the configuration source code  which is not 100  available to a policy check in HCP Terraform        expression representation      constant value  value      references  list of strings       There are two major parts to an expression representation     Any  strictly constant value  is expressed as an expression with a    constant value  field    Any expression that requires some degree of evaluation to generate the final   value   even if that value is known at plan time   is not expressed in   configuration  Instead  any particular references that are made are added to   the  references  field  More details on this field can be found in the    expression   representation   terraform internals json format expression representation    section of the JSON output format documentation   For example  to determine if an output is based on a particular resource value  one could do       import  tfconfig v2  as tfconfig  main   rule    tfconfig outputs  instance id   value references is   aws instance foo               Note    The representation does not account for complex interpolations or other expressions that combine constants with other expression data  For example  the partially constant data in   foo  var bar    would be lost       Block Expression Representation  Expanding on the above  a multi value expression representation  such as the kind found in a   resources    the resources collection  collection element  is similar  but the root value is a keyed map of expression representations  This is repeated until a  scalar  expression value is encountered  ie  a field that is not a block in the resource s schema        block expression representation       attribute key           child block expression representation                            constant value  value          references  list of strings       As an example  one can validate expressions in an   aws instance   https   registry terraform io providers hashicorp aws latest docs resources instance  resource using the following       import  tfconfig v2  as tfconfig  main   rule    tfconfig resources  aws instance foo   config ami constant value is  ami abcdefgh012345         Note that  nested blocks   sometimes known as  sub resources   will be nested in configuration as a list of blocks  reflecting their ultimate nature as a list of objects   An example would be the  aws instance  resource s   ebs block device   https   registry terraform io providers hashicorp aws latest docs resources instance ebs ephemeral and root block devices  block       import  tfconfig v2  as tfconfig  main   rule    tfconfig resources  aws instance foo   config ebs block device 0  volume size   10           The  providers  Collection  The  providers  collection is a collection representing the configurations of all provider instances across all modules in the configuration   This collection is indexed by an opaque key  This is currently  module address provider alias   the same value as found in the  provider config key  field   module address  and the colon delimiter are omitted for the root module   The  provider config key  field is also found in the  resources  collection and can be used to locate a provider that belongs to a configured resource   The fields in this collection are as follows      provider config key    The opaque configuration key  used as the index key     name    The name of the provider  ie   aws      full name    The fully qualified name of the provider  e g   registry terraform io hashicorp aws      alias    The alias of the provider  ie   east   Empty for a default provider     module address    The address of the module this provider appears in     config    A  block expression   representation   block expression representation  with provider configuration   values     version constraint    The defined version constraint for this provider      The  resources  Collection  The  resources  collection is a collection representing all of the resources found in all modules in the configuration   This collection is indexed by the resource address   The fields in this collection are as follows      address    The resource address  This is the index of the collection     module address    The module address that this resource was found in     mode    The resource mode  either  managed   resources  or  data   data   sources      type    The type of resource  ie   null resource  in  null resource foo      name    The name of the resource  ie   foo  in  null resource foo      provider config key    The opaque configuration key that serves as the index   of the   providers    the providers collection  collection     provisioners    The ordered list of provisioners for this resource  The   syntax of the provisioners matches those found in the     provisioners    the provisioners collection  collection  but is a list   indexed by the order the provisioners show up in the resource     config    The  block expression   representation   block expression representation  of the configuration values   found in the resource     count    The  expression data   expression representations  for the  count    value in the resource     for each    The  expression data   expression representations  for the    for each  value in the resource     depends on    The contents of the  depends on  config directive  which   declares explicit dependencies for this resource      The  provisioners  Collection  The  provisioners  collection is a collection of all of the provisioners found across all resources in the configuration   While normally bound to a resource in an ordered fashion  this collection allows for the filtering of provisioners within a single expression   This collection is indexed with a key following the format  resource address index   with each field matching their respective field in the particular element below      resource address   The address of the resource that the provisioner was found   in  This can be found in the   resources    the resources collection    collection     type   The provisioner type  ie   local exec      index   The provisioner index as it shows up in the resource provisioner   order     config   The  block expression   representation   block expression representation  of the configuration values   in the provisioner      The  variables  Collection  The  variables  collection is a collection of all variables across all modules in the configuration   Note that this tracks variable definitions  not values  See the   tfplan v2   variables  collection   terraform cloud docs policy enforcement sentinel import tfplan v2 the variables collection  for variable values set within a plan   This collection is indexed by the key format  module address name   with each field matching their respective name below   module address  and the colon delimiter are omitted for the root module      module address    The address of the module the variable was found in     name    The name of the variable     default    The defined default value of the variable     description    The description of the variable      The  outputs  Collection  The  outputs  collection is a collection of all outputs across all modules in the configuration   Note that this tracks variable definitions  not values  See the   tfstate v2   outputs  collection   terraform cloud docs policy enforcement sentinel import tfstate v2 the outputs collection  for the final values of outputs set within a state  The   tfplan v2   output changes  collection   terraform cloud docs policy enforcement sentinel import tfplan v2 the output changes collection  also contains a more complex collection of planned output changes   This collection is indexed by the key format  module address name   with each field matching their respective name below   module address  and the colon delimiter are omitted for the root module      module address    The address of the module the output was found in     name    The name of the output     sensitive    Indicates whether or not the output was marked as     sensitive    terraform language values outputs sensitive suppressing values in cli output      value    An  expression representation   expression representations  for the output     description    The description of the output     depends on    A list of resource names that the output depends on  These are   the hard defined output dependencies as defined in the     depends on    terraform language values outputs depends on explicit output dependencies    field in an output declaration  not the dependencies that get derived from   natural evaluation of the output expression  these can be found in the    references  field of the expression representation       The  module calls  Collection  The  module calls  collection is a collection of all module declarations at all levels within the configuration   Note that this is the   module    terraform language modules calling a child module  stanza in any particular configuration  and not the module itself  Hence  a declaration for  module foo  would actually be declared in the root module  which would be represented by a blank field in  module address    This collection is indexed by the key format  module address name   with each field matching their respective name below   module address  and the colon delimiter are omitted for the root module      module address    The address of the module the declaration was found in     name    The name of the module     source    The contents of the  source  field     config    A  block expression   representation   block expression representation  for all parameter values   sent to the module     count    An  expression representation   expression representations  for the    count  field     depends on   An  expression representation   expression representations  for the    depends on  field     for each    An  expression representation   expression representations  for   the  for each  field     version constraint    The string value found in the  version  field of the   module declaration