terraform-aws-security-baseline - Terraform baseline for implementing essential AWS security best practices, including Organizations, SSO, MFA, SCPs, Budget Alarms, CloudTrail, and secure S3 configuration.

Automate your AWS account security setup with infrastructure as code.

🧠 USE CASE

The Problem With Overusing Terraform Dynamic Blocks

As Terraform professionals, we aim for elegant, maintainable infrastructure code.

But even seasoned engineers can trip over pitfalls like the overuse of dynamic blocks or misunderstand the scope of terraform apply.

Before talking about that….

Yesterday, I shared a 71-page "TERRAFORM BASICS TO ADVANCED IN ONE GUIDE" to help you build strong, long-term success.

I shared this freebie to celebrate hitting 100 editions of this newsletter.

I’m happy to see that 20,000+ people grabbed it, and this support gives me the strength to bring more exciting content.

Back to context…

For someone new, A dynamic block in Terraform is a way to programmatically generate multiple nested blocks within a resource or module.

It’s typically used when the number of configurations is variable and cannot be hardcoded.

You can find more about the dynamic block use cases here.

The Problem with Overusing Dynamic Block

📌 Too many nested dynamic blocks obscure intent and reduces readability.

📌 Errors inside dynamic blocks are less intuitive because the block's logic is abstracted.

📌 Refactoring becomes challenging since dynamic blocks tightly couple logic and resource definitions.

🚩 Example of Overuse:

resource "aws_security_group" "techops" {

name = "techops-sg"

vpc_id = var.vpc_id

dynamic "ingress" {

for_each = var.ingress_rules

content {

from_port = ingress.value.from_port

to_port = ingress.value.to_port

protocol = ingress.value.protocol

cidr_blocks = ingress.value.cidr_blocks

}

✅ Better Alternative:

Instead of relying on dynamic, use for_each at a higher level for simplicity:

resource "aws_security_group_rule" "ingress" {

for_each = var.ingress_rules

type = "ingress"

security_group_id = aws_security_group.techops.id

from_port = each.value.from_port

to_port = each.value.to_port

protocol = each.value.protocol

cidr_blocks = each.value.cidr_blocks

}

Why? This creates one resource per rule, making debugging and maintenance more straightforward.

⚠️ Misconceptions About Terraform Apply

terraform apply is powerful but not omnipotent. It can:

Provision resources
Destroy resources

However, it cannot:

Import resources into state: If a resource already exists outside Terraform, terraform apply won't recognize it. You must explicitly run terraform import.

What do I Mean ?

Let’s say your team starts managing existing S3 buckets using Terraform.

Running terraform apply without importing those buckets first might result in an error or, worse, accidental destruction.

So, Import it into state:

terraform import aws_s3_bucket.techops my-bucket

Run terraform plan to ensure no drift.

Check This Out:

Hands-On Resource Import Guide
Step-by-step instructions for importing existing resources into Terraform state without disruptions.

You may even like:

Guide to a Well Structured Terraform Project

Looking to promote your company, product, service, or event to 27,000+ TechOps Professionals? Let's work together.