D is the right answer. I tested in my local machine to create Sql server with 2 environment vaiables $env:TF_VAR_sql_admin = "username" and $env:TF_VAR_sql_password = "sqldbpassword" Also created the SQL Server with Terraform which accesses env variable during execution. BUT FOUND MY SENSITIVE ENVIRONMENT VARIABLE VALUES ARE STILL LISTED IN THE "STATE FILE" so answer should be "D"

When you use environment variables to store credentials, Terraform does not include these credentials in the state file. Environment variables are read at runtime, which means they are not persisted in the configuration files or the state file.

Answer is A 100%: Using environment variables We already use Terraform this way: Bash export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY" Terraform provider "aws" { access_key = "YOUR_ACCESS_KEY" secret_key = "YOUR_SECRET_KEY" }

Using environment variables

1. Code example: ... resource "azurerm_sql_server" "example" { name = "example-sqlserver" resource_group_name = azurerm_resource_group.example.name location = azurerm_resource_group.example.location version = "12.0" administrator_login = var.sql_admin_username administrator_login_password = var.sql_admin_password } variable "sql_admin_username" {} variable "sql_admin_password" {} ... 2. Set env variables: export TF_VAR_sql_admin_username="adminuser" export TF_VAR_sql_admin_password="SuperSecretPassword" 3. terraform init 4. terraform apply 5. After applying, if you inspect the state file (terraform.tfstate), you will find that it contains the administrator login and password.

Terraform Enterprise and Terraform Cloud credentials are not stored in Terraform state or the CI/CD platform. Therefore, the correct answer to your question is D. None of the above.

nswer: using environment variables The only method list above that will not result in the username/password being written to the state file is environment variables. All of the other options will result in the provider's credentials in the state file. Terraform runs will receive the full text of sensitive variables, and might print the value in logs and state files if the configuration pipes the value through to an output or a resource parameter. Additionally, Sentinel mocks downloaded from runs will contain the sensitive values of Terraform (but not environment) variables. Take care when writing your configurations to avoid unnecessary credential disclosure. Whenever possible, use environment variables since these cannot end up in state files or in Sentinel mocks. (Environment variables can end up in log files if TF_LOG is set to TRACE.)

All secrets will end up in statefile.

It's D only currently there is no way to prevent it

nothign prevents this, only thing is we can encrytp answer is D

Refer: https://developer.hashicorp.com/terraform/language/values/variables Setting a variable as sensitive prevents Terraform from showing its value in the plan or apply output, when you use that variable elsewhere in your configuration. Terraform will still record sensitive values in the state, and so anyone who can access the state data will have access to the sensitive values in cleartext. For more information, see Sensitive Data in State.

The answer is A. Using environment variables. Here is an example of how to use environment variables to provide authentication credentials for an AWS provider: provider "aws" { region = var.aws_region access_key_id = var.aws_access_key_id secret_access_key = var.aws_secret_access_key }

No, environment variables are not safe to store credentials in the state file of Terraform. Environment variables can be accessed by any process running on the same machine, including potentially malicious processes. It's important to use a secure method of storing credentials, such as using a secrets manager or key vault. Additionally, it's important to ensure that the state file itself is properly secured, either by encrypting it or by storing it in a secure location.

I think correct answer is A. I have checked in my remote state file sitting in Azure storage account. (I used Azure DevOps environment variables) secret files are not visible in the state file.

Opt A. If you look into official terraform provider documentation, including terraform enterprise, all providers point to "Dynamic Provider Credentials". This workflow generally exposes a temporary OIDC compliment token as environment variable and authenticated by cloud providers. So I would say the straight forward answer would be environment variables.

Definitely "D", I wonder how A is the even an "authentication method"? Read the question carefully, or am I trying to read in between the lines?

None of the above options prevents credentials from being stored in the state file. Storing credentials in Terraform code or environment variables is not recommended, as it can expose sensitive information and make it more difficult to manage and rotate credentials. Instead, you should use an external authentication method, such as the "external" authentication method in Terraform, which allows you to execute an external program to obtain authentication credentials at runtime, rather than storing the credentials in the state file. This method keeps your credentials secure and allows you to use authentication mechanisms that do not expose credentials in plain text or that require interactive authentication.