Courseiva
Understand IaC conceptshardMultiple ChoiceObjective-mapped

TF-004 Understand IaC concepts Practice Question

A Terraform configuration includes a variable for a database password marked as sensitive. When a user runs 'terraform apply', the password appears as (sensitive) in the plan output. However, they want to pass this password to a provisioner as an environment variable. What should they do?

⚠ Common exam trap

Candidates often assume the sensitive flag only affects CLI output, leading them to choose Option A, but Terraform enforces sensitivity in all contexts unless `nonsensitive()` is used.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Use the nonsensitive() function around the variable when assigning.

The `nonsensitive()` function explicitly marks a sensitive value as safe to use in contexts where Terraform would otherwise block its usage, such as passing it to a provisioner's environment variable. Even though the variable is marked as sensitive, Terraform still prevents it from being used in certain contexts unless you explicitly override that protection with `nonsensitive()`. This ensures the password is available to the provisioner while still hiding it from CLI output.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Use the variable directly; sensitive only affects CLI output.

    Why it's wrong here

    Directly using a variable marked `sensitive = true` means its value will be redacted in `terraform plan` and `terraform apply` output, appearing as `(sensitive value)`. However, the `sensitive` flag's effect extends beyond just CLI output; it also ensures the value is stored as sensitive within the Terraform state file and redacted in logs or remote state UIs. Therefore, simply using the variable directly does not expose it in CLI output, but it maintains its sensitive status throughout the Terraform lifecycle, preventing its display in various outputs and storage contexts.

  • Use the nonsensitive() function around the variable when assigning.

    Why this is correct

    The `nonsensitive()` function explicitly marks a sensitive value as non-sensitive for a specific expression or assignment, allowing it to be used in contexts where a sensitive value would otherwise be redacted or cause an error. Crucially, while `nonsensitive()` permits its use in a particular operation or argument, the original variable's value *remains marked sensitive within the Terraform state file*. This ensures the value is only exposed when explicitly intended for processing, maintaining its sensitive status for storage and subsequent operations.

  • Store the password in a local value with sensitive = false.

    Why it's wrong here

    Storing a password in a local value, even if you attempt to mark it as non-sensitive, would typically result in its cleartext display during `terraform plan` and `terraform apply` operations. Local values are primarily designed for simplifying expressions and are not a mechanism for securing sensitive data; they propagate the sensitivity of their inputs or expose cleartext if derived from non-sensitive sources. Therefore, this approach would expose the password in plan output, defeating the purpose of the `sensitive` flag.

  • Remove the sensitive flag from the variable.

    Why it's wrong here

    Removing the `sensitive` flag from the variable definition would cause the database password to be displayed in cleartext within `terraform plan` and `terraform apply` output, as well as stored unencrypted in the Terraform state file. This action completely negates the security benefits of the `sensitive` flag, making the password vulnerable to exposure in logs, version control systems (if state is committed), and anyone with access to the state file. It is a severe security misconfiguration for credentials.

About these practice questions

This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.