Why should secrets not be hard coded into Terraform code? (Choose two.)
Why should secrets not be hard coded into Terraform code? (Choose two.)
Hard coding secrets into Terraform code creates several issues. Firstly, it makes the code less reusable because the secrets are tied to a specific environment or set of credentials, requiring modifications for use in different contexts. Secondly, Terraform code is typically stored in version control systems and may be copied to various locations where it is executed, such as a developer's machine or CI/CD pipeline. These locations might lack robust security mechanisms, exposing the secrets to potential unauthorized access.
AB, terraform code will not be copied to target resource, if you deploy a VM the code will not copied to the VM
Selected Answer: AB
Explanation: A. It makes the code less reusable: Hard coding secrets means the Terraform code is tied to a specific environment or set of credentials. This makes it hard to reuse the code in different contexts or environments without modifying the secrets. B. Terraform code is typically stored in version control, as well as copied to the systems from which it's run. Any of those may not have robust security mechanisms: Storing secrets directly in the Terraform code exposes those secrets to anyone who has access to the code. Furthermore, secrets may be logged in version control history, making them discoverable long after they've been removed or changed.
These are DevSecOps best practice options
What the hell some people are voting for A!!!!
The code will not be copied to Resources hence C is wron A is correct because if a secret to connect to a DB or backed is used in code and if the code is executed where they use a diffrent DB/backend the code cannot run. So hard coding passwords makes the code less usable
Code will not be copied to target location
A, because "hard coding" in general makes code less re-usable. B, VCS is also true, this might expose the password
answer is AB C is wrong, as yaza said, terraform code will not be copied to target resource, if you deploy a VM the code will not copied to the VM
A and B are good answers
B and C are security related
B and C
Exactly 💯
Answer is B and C, as its a serious security breach. A - just mentions about best practices.
B and C. My Terraform source code is in github repo, and when I use pipelines to run terraform, the source code gets downloaded in the CI/CD or build server or terraform server and access holder to this server could see them. The question terms this server as the target resource. Yes, hardcoding does make it less reusable, but there is a way around- using environment specific tfvars.
I vote A and B, because C doesn't make sense. Why would the terraform code be copied to the target resources? For example, I provision an Azure Storage account using terraform. There's no point at which the terraform code ends up on that storage account.
i choose A and B
BC in my opinion
B&C is the correct answer
B. Terraform code is typically stored in version control, as well as copied to the systems from which it's run. Any of those may not have robust security mechanisms. C. The Terraform code is copied to the target resources to be applied locally and could expose secrets if a target resource is compromised. Storing secrets, such as passwords or API keys, directly in Terraform code is a bad practice for several reasons. Firstly, Terraform code is typically stored in version control, and it may be copied to multiple systems from which it's run, such as a developer's machine, a CI/CD pipeline, or a Terraform cloud workspace. Any of those systems may not have robust security mechanisms, and exposing secrets in code leaves them vulnerable to potential attacks. Secondly, the Terraform code is copied to the target resources to be applied locally, so any secrets in the code could be exposed if a target resource is compromised. Therefore, it is recommended to use a secrets management system, such as HashiCorp Vault or AWS Secrets Manager, to store and manage secrets outside of Terraform code.
agreed
def, BC
For me the answer C does not make sense...
B. Terraform code is typically stored in version control, as well as copied to the systems from which it's run. Any of those may not have robust security mechanisms. Storing secrets in plain text within code, especially if it's publicly accessible or shared, increases the risk of the secrets being compromised. If the code is stored in a version control system, it's important to ensure that the secrets are not accidentally exposed in the version history. C. The Terraform code is copied to the target resources to be applied locally and could expose secrets if a target resource is compromised. If the Terraform code contains secrets, then those secrets will be copied to the target resources during the deployment process. If any of the target resources are compromised, the secrets may be exposed. It's important to keep secrets separate from the code and ensure that they are securely transmitted to the target resources when needed.
Will the code be copied though ?
A and B
AB, I don't think a terraform code is copied to any place(local, backend, any modules etc.,) But, The values of the variables are rendered into the state file. where the key/secrets are exposed
Seems like BC are correct answers , A is like ambiguity type means so we've to follow the best practices seems like not related to this question
AB, Hardcoding secrets (like passwords) in Terraform is bad because: Sharing Risk: If the code is shared or stored, anyone can see the secrets and misuse them. Hard to Reuse: If you want to use the code somewhere else, you’d have to change the secrets every time. Keeping secrets separate is safer and makes the code easier to use again.
Version Control Exposure (B): Terraform code is often stored in repositories (e.g., GitHub, GitLab). Secrets in code become visible in commit histories, even if later removed. Systems running Terraform (e.g., CI/CD pipelines) may lack proper security controls, exposing secrets in logs or environment variables. Target Resource Compromise (C): Secrets embedded in user data or scripts (e.g., cloud-init) may be stored on provisioned resources (e.g., VMs). If compromised, attackers can extract secrets directly from the resource.