Day 13 of my 30-Day Terraform Challenge was focused on one of the most important production topics in Infrastructure as Code: handling secrets securely.
Today’s work was less about deploying flashy infrastructure and more about learning how easily sensitive data can leak if Terraform is not configured carefully.
It was a very practical lesson because secrets are everywhere in cloud environments:
- database passwords
- API keys
- tokens
- access credentials
- connection strings
And if they are not handled properly, they can end up exposed in places you might not immediately think about.
Why Secret Management Matters in Terraform
Terraform makes it very easy to define infrastructure in code, but that also creates risk.
The moment you start working with values like passwords or credentials, you have to think about where those values live and who can see them.
A secret does not have to be directly printed in your code to be leaked.
It can show up in:
- Terraform files
- terminal output
- logs
- state files
- version control
- backend storage
That means secret management is not just one problem — it is a set of security risks across the Terraform workflow.
The Three Main Secret Leak Paths
One of the biggest takeaways from today was learning that there are three major places secrets can leak when using Terraform.
1. Secrets hardcoded in .tf files
This is the most obvious mistake.
If you directly write a password or API key in a Terraform file, then anyone who has access to the codebase can see it.
That includes:
- teammates
- collaborators
- Git history
- backups
- accidental commits
This is the easiest kind of leak to avoid, but it is also one of the most common mistakes beginners make.
2. Secrets exposed in plan and apply output
Even if a secret is not hardcoded in a file, Terraform can still print it to the terminal if you are not careful.
That means secrets can accidentally appear in:
- screenshots
- logs
- CI/CD pipelines
- recorded demos
- shell history
This is especially dangerous because people often assume that if a secret is not in the .tf file, then it is automatically safe.
That is not true.
3. Secrets stored in Terraform state
This was the most important lesson of the day.
Even if a secret is hidden in terminal output and not stored directly in code, Terraform may still keep it in the state file.
That means the state file becomes one of the most sensitive assets in your Terraform workflow.
If someone can access your state file, they may still be able to retrieve sensitive information.
That is why protecting state is such a critical part of Terraform security.
Using AWS Secrets Manager Instead of Hardcoding Values
To avoid placing secrets directly in my Terraform files, I used AWS Secrets Manager.
This was a much better pattern because the secret value lived in AWS instead of inside my code.
Terraform only referenced the secret when it needed to use it.
That gave me a much safer workflow because:
- the actual password did not appear in my
.tffiles - the secret was centrally stored
- the secret could be managed outside the Terraform codebase
This is a much more realistic pattern for production infrastructure.
Why sensitive = true Matters
Another important thing I practiced today was using sensitive = true on variables and outputs.
This tells Terraform to hide the value in CLI output.
That means instead of printing the actual value, Terraform shows:
(sensitive value)
This is useful because it helps reduce accidental leaks in:
- terminal output
- logs
- screenshots
- demos
And it worked exactly as expected during my apply output.
That said, today also taught me something very important:
sensitive = true is not enough on its own
It only protects display output.
It does not mean Terraform stops storing the value in state.
That distinction is extremely important.
Securing Terraform State Properly
Since Terraform state may still contain sensitive values, securing the backend is essential.
For this challenge, I used an S3 backend with the right protections in mind.
The security measures I focused on included:
- encryption enabled
- versioning enabled
- public access blocked
- access restricted through IAM
This made me realize that in real-world Terraform usage, protecting state is just as important as protecting code.
A lot of teams focus on hiding secrets in variables but forget that state is often where the real exposure risk still exists.
That was one of the strongest lessons from today.
Why .gitignore Matters More Than It Seems
Another small but very important part of today’s work was making sure Terraform files that should never be committed are excluded from Git.
That includes things like:
.tfstate.tfvars.terraform/- backup state files
This matters because many secret leaks happen not from Terraform itself, but from accidental commits.
A strong .gitignore is a simple but important layer of protection.
It is one of those small things that can prevent very big mistakes.
HashiCorp Vault vs AWS Secrets Manager
Today also pushed me to think more broadly about where secrets should live.
I learned that:
AWS Secrets Manager is great when:
- your infrastructure is mostly in AWS
- you want native AWS integration
- you need a simpler managed secrets workflow
HashiCorp Vault is better when:
- you are working across multiple clouds
- you need dynamic secrets
- you want more advanced centralized secrets management
That comparison was useful because it showed that secure secret handling is not only about Terraform syntax — it is also about choosing the right tool for your environment.
Challenges I Faced
One issue I ran into was that Terraform could not read the secret until it actually existed in AWS Secrets Manager.
That meant I had to create the secret first before Terraform could successfully reference it.
I also had to make sure the JSON structure inside the secret matched exactly with what Terraform expected.
That is a small detail, but if the keys do not match, Terraform will fail when trying to decode and reference the values.
Finally, I had to be very clear in my understanding of what sensitive = true actually does.
At first glance, it feels like full protection, but in reality it is just output masking, not full secret protection.
That was probably the biggest conceptual lesson from today.
What I Learned from Day 13
Day 13 taught me that secret management in Terraform is not just about “hiding passwords.”
It is about understanding the entire lifecycle of sensitive data:
- where it is defined
- where it is displayed
- where it is stored
- where it might accidentally leak
The biggest lessons for me were:
- never hardcode secrets in Terraform files
- use a secret manager whenever possible
- mark sensitive values properly
- protect Terraform state seriously
- never assume a hidden CLI value means the secret is fully safe
This was one of the most practical and security-focused challenge days so far.
Final Thoughts
Day 13 reminded me that secure infrastructure is not just about provisioning resources — it is also about protecting the information that makes those resources work.
Terraform is powerful, but with that power comes responsibility.
Learning how to handle secrets properly is one of the most important habits to build early.
And I’m glad this challenge included it, because it made me think more like someone building real production infrastructure, not just completing labs.
Connect With Me
I’m documenting my journey through the 30-Day Terraform Challenge as I continue learning more about:
- Terraform
- AWS
- Infrastructure as Code
- DevOps best practices
- Cloud security
If you are also learning cloud or IaC, feel free to connect.
Top comments (0)