Terraform security and governance practice questions

Sensitive HCP Terraform variables are write-only: no user or API call can read them back, and their attributes cannot be edited.

Marking a variable sensitive makes it write-only for everyone, including organization owners and API clients. Its value can be replaced, but its other attributes, such as the sensitive flag, cannot be changed. The documented route is to delete the variable and create a new one with the same key and the desired settings.

1. Recall that sensitive means write-only for all users and the API.
2. Note that the sensitive flag is one of the attributes that cannot be edited.
3. Choose deleting and recreating the variable.

Exam tip: A sensitive workspace variable can be replaced or deleted, never unmasked or edited back.

A sensitive workspace variable hides the value in HCP Terraform's UI and API, but the run receives the full value and can still put it into state or logs.

Two facts combine. First, the run gets the real value, and an ordinary resource argument is persisted in state, so the password is in state no matter how the variable was flagged. Second, environment variables never reach state, but HashiCorp documents that TF_LOG=TRACE can print them into run logs. Sensitive variables are never readable through the API, and nothing redacts values inside state.

1. Separate the two variable categories: environment variables and Terraform variables.
2. Ask where each value flows: an ordinary resource argument is persisted in state.
3. Recall that TRACE logging can include environment variables.
4. Reject claims that sensitive values are readable through the API or redacted in state.

Exam tip: Sensitive hides a value from people, not from the run: watch state and TRACE logs.

In HCP Terraform, reading state versions means reading the full state, secrets included; outputs-only access is a separate custom permission level.

Every fixed permission set, Read included, can read complete state versions. Because state can hold secrets, a team that only needs outputs should get custom workspace access with state versions set to Read outputs only. Custom Read on state versions is the near-twin and exposes the full file.

1. Note that the state contains credentials.
2. Recall that every fixed permission set includes reading full state versions.
3. Pick the custom level that exposes only outputs.

Exam tip: Outputs-only consumers get 'Read outputs only', never a set that reads full state.

Read access to state versions is part of every fixed workspace permission set, so state holding secrets is exposed to any team with workspace access.

The Plan set lets a team queue plans, and like every fixed set it also includes reading complete state versions. Because the password was passed to a resource argument it is in state, so the developer could download it. Sensitive variables are never readable, plan logs redact sensitive values, and writing state is a Write/Admin capability.

1. Identify where the password can be read: state, not the variable.
2. Recall what the fixed Plan set includes besides queuing plans.
3. Rule out the variable and log options, which stay hidden.

Exam tip: Any fixed workspace permission set can read full state; protect state as a secret.

Ephemeral resource results are valid only in a short list of contexts; using one in an ordinary managed-resource argument is a plan-time error.

Terraform throws an error at plan time when an ephemeral resource is referenced outside the permitted contexts: write-only arguments, other ephemeral blocks, locals, ephemeral variables and child-module outputs, provider configuration, and provisioner/connection blocks. The data map of kubernetes_secret_v1 is an ordinary argument that would be persisted, so the configuration is invalid rather than silently stored or redacted.

1. Identify the reference: an ephemeral attribute flows into a managed resource.
2. Check whether the argument is write-only; data is not.
3. Recall that invalid ephemeral references fail at plan.

Exam tip: Ephemeral values may only flow into places Terraform never persists.

Ephemeral values can be used only where Terraform does not persist them.

The permitted contexts are write-only arguments, provider configuration, locals, other ephemeral blocks, ephemeral variables and child-module outputs, and provisioner/connection configuration. Root outputs, ordinary resource arguments such as tags and data source arguments all end up in state or plan, so references there fail at plan time.

1. Ask whether each location is persisted in state or plan.
2. Recall the permitted contexts list.
3. Note that sensitive = true does not make a root output ephemeral.

Exam tip: Provider config and write-only arguments take ephemeral values; anything persisted does not.