Terraform Associate Exam - Question 43

It's D We can use providers to supply variable values (vault for example). We can provide input variable value in parameter for apply command. We can use environment variables. HashiCorp is not mentioning anything about secure strings. Reference: https://www.terraform.io/language/values/variables

i think D

Answer is A A Terraform provider is a software library that allows Terraform to interact with a particular cloud provider or other infrastructure service. Terraform providers do not have the ability to store secrets, so they cannot be used to keep secrets out of Terraform configuration files.

A is incorrect, A provider can also declare an attribute as sensitive, which will cause Terraform to hide it from regular output regardless of how you assign it a value. Ref. https://developer.hashicorp.com/terraform/language/values/variables

Answer is D. A. Terraform Provider: You can use sensitive variables in Terraform Cloud (below link) or other secrets management solutions (e.g. AWS Secrets Manager). Sensitive variables / sensitive values is described here: https://developer.hashicorp.com/terraform/cloud-docs/workspaces/variables/managing-variables#sensitive-values B. Environment Variables: You can use environment variables. Terraform will read environment variables that start with TF_VAR_, followed by the name of a declared variable in your configuration. C. -var flag: You can use the -var command line flag. This is useful for setting sensitive data that should not be stored in your configuration. e.g. terraform apply -var 'db_password=My$ecretP@ssw0rd' D. "secure string" is not a valid option for keeping secrets out of Terraform configuration files. The term "secure string" is not a recognized or standard feature in Terraform.

Bad answers for this question. Definitely you cannot use a terraform provider to keep secrets out of your terraform configuration. Even if you use Vault, you must provide the Vault itself secrets and or you save to a file, in an environment variable, or within the provider itself. So "A" is wrong. The issue is that "D" is also wrong. A and D should be the answers for this question in my opinion.

I will go for A. All other options are to keep secrets out of Terraform configuration files, you typically use environment variables, a -var flag, or secure string variables.

Answer is: A. Terraform provider It says: to Hide secrets and not include secrets. Here's why the other options are suitable for hiding secrets: B. Environment variables: Environment variables store sensitive information outside of Terraform code, and Terraform can access them during execution. C. A -var flag: The -var flag allows passing secrets as command-line arguments when running terraform apply or other commands. These arguments aren't stored in the configuration files. D. Secure string: Some Terraform providers (like AWS) offer functionality to store secrets securely within the provider itself (e.g., AWS Secrets Manager). This keeps them out of the configuration files.

I think it is A. Provider has nothing to do with secret Managment.

It's D.

Terraform does not have a built-in "secure string" option

D is correct because all other options can be used to keep secrets out of terraform config files

C is the answer

D, "secure string"

D is correct.. In Terraform, the term "secure string" isn't a specific built-in type or feature by that name. However, the concept of treating certain strings as "secure" or sensitive is indeed present in Terraform, particularly through the use of the sensitive attribute for variables and outputs. When we refer to a "secure string" in the context of Terraform, it's generally about handling sensitive values such as passwords, secret keys, or any confidential data that should not be exposed in logs or CLI output. Here's how you can declare a variable as sensitive: variable "api_secret_key" { type = string sensitive = true }

can not be used to keep secrets D - Secret String

swear to god these questions are worded so fking poorly