A root configuration sets access_key and secret_key directly in the aws provider block, read from variables whose default values are committed to the repository. The team runs Terraform both from laptops and from HCP Terraform workspaces. What is the recommended change?
Select an answer to reveal the explanation.
Short Explanation
Credentials in a provider block are like taping your house key to the front door: convenient, and a gift to anyone walking by. Leave the provider block empty of secrets and let it pick up credentials from your environment, and in HCP Terraform let dynamic credentials hand out short-lived ones. Sensitive and tfvars just move the tape.
Full Explanation
Providers such as aws read credentials from standard sources when no explicit arguments are set: environment variables, shared configuration and credential files, single sign-on profiles, and instance or workload identities. Removing access_key and secret_key from the provider block lets each execution environment supply its own identity: an engineer's short-lived profile session on a laptop, and dynamic provider credentials in HCP Terraform workspaces, where the run assumes a role through workload identity. No key remains in the repository or the configuration. Moving the defaults into terraform.tfvars changes only the file name; the keys stay in version control, and terraform.tfvars has nothing to do with state. Marking the variables sensitive redacts output but does not remove the committed defaults from Git, and sensitive values are still stored where Terraform persists them. A backend block configures state storage, not provider authentication; backend credentials are a separate concern and are also persisted in the working directory, so it would add a second exposure. Exam caveat: committed keys must be rotated after removal, because history still contains them. Operational check: delete the arguments and defaults, run terraform plan locally with a profile and in HCP Terraform with dynamic credentials, and confirm both authenticate.