Skip to content
Cheat sheets

004 · Domain 4: Terraform configuration · 13% of the exam

Task 4.8: Understand best practices for managing sensitive data, including secrets management with Vault

Sensitive variables and outputs, what still lands in state, ephemeral variables, outputs and resources, write-only arguments, and reading secrets from Vault with the Vault provider.

Study it

Sample questions

Try each one before opening the answer. Every option is explained, with the HashiCorp documentation page that proves it.

Question 1 · choose 1

A pipeline passes a short-lived API token into a configuration only to configure a provider. The token must not end up in state or in saved plan files. How should the input variable be declared? (Terraform 1.12)

  1. AWith ephemeral = true, so it is usable during the run but never stored
  2. BWith a default of the token value, so it does not have to be passed on the command line
  3. CWith nullable = false, so Terraform refuses to write the value anywhere
  4. DWith type = string and a validation block that rejects stored values
Show the answer and why

  • AWith ephemeral = true, so it is usable during the run but never stored

    Correct

    The ephemeral argument makes a variable available at runtime while Terraform omits it from state and plan files; it can be used in contexts such as provider blocks.

  • BWith a default of the token value, so it does not have to be passed on the command line

    Incorrect

    A default puts the secret into the configuration itself.

  • CWith nullable = false, so Terraform refuses to write the value anywhere

    Incorrect

    nullable only controls whether null is accepted.

  • DWith type = string and a validation block that rejects stored values

    Incorrect

    Validation checks values; it cannot control where Terraform stores them.

Ephemeral variables (Terraform 1.10 and later) exist only for the run; nothing about them is written to state or plans.

HashiCorp documentation

Task 4.8Report a problem with this question

Question 2 · choose 1

A variable db_password is marked sensitive = true and is used in a resource argument. What does the plan output show for that argument?

  1. AThe password in plain text, since only outputs can be sensitive
  2. BA hash of the password, so changes can be compared
  3. CNothing; the argument is removed from the plan entirely
  4. D(sensitive value), as derived expressions are sensitive too
Show the answer and why

  • AThe password in plain text, since only outputs can be sensitive

    Incorrect

    Variables can be sensitive too.

  • BA hash of the password, so changes can be compared

    Incorrect

    The plan shows a redaction marker, not a hash.

  • CNothing; the argument is removed from the plan entirely

    Incorrect

    The argument is listed with its value redacted.

  • D(sensitive value), as derived expressions are sensitive too

    Correct

    Terraform redacts sensitive values in plan and apply output, and any expression that uses a sensitive variable becomes sensitive.

Sensitivity follows the value through expressions into plan output.

HashiCorp documentation

Task 4.8Report a problem with this question

Question 3 · choose 1

An engineer adds ephemeral = true to an output in the root module and gets an error. Where can outputs be ephemeral?

  1. AOnly in child modules, passing values up without storing them
  2. BOnly in the root module, to hide values from the CLI
  3. CIn any module, but only for outputs whose values are strings
  4. DNowhere; ephemeral is not an argument of output blocks
Show the answer and why

  • AOnly in child modules, passing values up without storing them

    Correct

    The ephemeral argument can be added to outputs in child modules; it cannot be added to outputs in the root module.

  • BOnly in the root module, to hide values from the CLI

    Incorrect

    Root module outputs cannot be ephemeral.

  • CIn any module, but only for outputs whose values are strings

    Incorrect

    The restriction is about the module, not the type.

  • DNowhere; ephemeral is not an argument of output blocks

    Incorrect

    The output block accepts ephemeral = true; the restriction is on where, not whether.

Ephemeral outputs carry values between modules during a run; the root module has nowhere ephemeral to send them.

HashiCorp documentation

Task 4.8Report a problem with this question

Question 4 · choose 1

A team keeps a prod.tfvars file with the database admin password in its Git repository. What is the better practice?

  1. AKeep the file but list it in the README so reviewers know it contains a secret
  2. BSupply it at run time, from a secret store or a sensitive HCP variable
  3. CKeep the file and mark the variable nullable = false
  4. DBase64-encode the password inside the file
Show the answer and why

  • AKeep the file but list it in the README so reviewers know it contains a secret

    Incorrect

    Documenting a committed secret does not protect it.

  • BSupply it at run time, from a secret store or a sensitive HCP variable

    Correct

    Secrets should not live in configuration or committed files; supply them from a secret store or as sensitive variables in HCP Terraform.

  • CKeep the file and mark the variable nullable = false

    Incorrect

    nullable is unrelated to secrecy.

  • DBase64-encode the password inside the file

    Incorrect

    Encoding is not encryption.

Secrets in Git are leaked secrets; keep them out of files you commit.

HashiCorp documentation

Task 4.8Report a problem with this question

Question 5 · choose 1

A team wants Terraform runs to use short-lived cloud credentials instead of long-lived keys on laptops. It already runs Vault with a cloud secrets engine. What does HashiCorp's tutorial show?

  1. AStore the long-lived keys as the default of a Terraform variable in the configuration
  2. BRead short-lived credentials through the Vault provider and pass them on
  3. CCopy the keys into the state file, which is encrypted by Vault
  4. DUse a provisioner that logs in to Vault on each instance
Show the answer and why

  • AStore the long-lived keys as the default of a Terraform variable in the configuration

    Incorrect

    That keeps long-lived keys in configuration.

  • BRead short-lived credentials through the Vault provider and pass them on

    Correct

    The tutorial uses the Vault provider to generate short-lived, scoped credentials from the secrets engine and passes them to the cloud provider.

  • CCopy the keys into the state file, which is encrypted by Vault

    Incorrect

    State is not a credential store, and Vault does not encrypt local state.

  • DUse a provisioner that logs in to Vault on each instance

    Incorrect

    The provider, not provisioners, reads credentials for Terraform itself.

Dynamic secrets shrink the window in which a leaked credential is useful.

HashiCorp documentation

Task 4.8Report a problem with this question

Question 6 · choose 1

A value derived from a sensitive variable is only its character length, which is not secret, but Terraform redacts it in outputs. How can the author show it deliberately?

  1. AWrap it in tostring()
  2. BSet sensitive = false on the variable for one run
  3. CWrap the expression in nonsensitive()
  4. DUse ephemeralasnull() on the expression
Show the answer and why

  • AWrap it in tostring()

    Incorrect

    Type conversion keeps the sensitive marking.

  • BSet sensitive = false on the variable for one run

    Incorrect

    That would expose the secret itself, not just its length.

  • CWrap the expression in nonsensitive()

    Correct

    nonsensitive removes the sensitive marking from a value when the author knows it reveals nothing secret.

  • DUse ephemeralasnull() on the expression

    Incorrect

    That function replaces ephemeral values with null; it does not remove sensitivity.

nonsensitive is an explicit, reviewable statement that a derived value is safe to show.

HashiCorp documentation

Task 4.8Report a problem with this question

Practise domain 4 →Practise all domains →