Infrastructure as Code and Automation Questions

I would use count or for_each for the feature flag, but I would prefer for_each for the per-item objects. count is a simple on or off switch. for_each creates one instance per stable key, which is better when the list order changes.

Pattern

• For the feature-flagged singleton, create either one instance or none
• For the repeated objects, convert the caller’s list into a map keyed by a stable ID, such as name
• Avoid indexing directly into a list, because reordering ['api', 'worker'] can cause unnecessary replacement

Example
If the caller passes ['api', 'worker'] today and ['worker', 'api'] tomorrow, keys like api and worker still point to the same resources. That keeps Terraform from churning objects just because the order changed.

Rule of thumb
Use count for a single optional resource, and for_each for anything that should survive list reordering. That makes the module much easier to maintain as the list grows.

I would put both human review and automation around the plan. A Terraform plan is a preview of create, update, destroy, and replace actions. Replace is especially risky because Terraform deletes and recreates a resource.

Guardrails

• Run terraform fmt -check and terraform validate in CI
• Save the plan as an artifact and require approval before apply
• Fail the pipeline if the plan includes unexpected destroys or replacements on critical resources
• Use policy checks for things like public exposure, open security groups, or deletion of databases
• Add prevent_destroy to the few resources that should almost never be removed

Example
If the plan shows aws_db_instance.main will be replaced because of an engine change, I would force manual review from an engineer and, ideally, a service owner. If the plan only adds an autoscaling instance, that can follow the normal path.

This catches surprises before users feel them, which is the real goal.

I would split the solution by responsibility, not by environment. A module should do one job well.

Module layout

• network: VPC, subnets, routes, NAT, and network tags
• compute: app instances, ECS or ASG, load balancer, security groups
• database: managed DB, subnet group, parameter group, DB security group
• root stack: wires the outputs together

Why this works
The network changes slowly, compute changes often, and the database has its own lifecycle and risk. Keeping them separate reduces blast radius and makes reviews easier.

Safe interface
I would expose only what callers need:

• From network: vpc_id, private_subnet_ids, public_subnet_ids
• From compute: alb_dns_name, app_sg_id
• From database: endpoint, port, and maybe a secret reference, not a password

Example
The root module can pass private_subnet_ids = ["subnet-101", "subnet-202"] into compute and database, while dev and prod use different sizes through variables. That keeps composition flexible without letting one team edit module internals.

Decision framework
I first determine whether Terraform should own the object. A resource should be imported only if the team wants Terraform to manage its lifecycle and we can make the current cloud object match code with low risk. If ownership is unclear or another team runs it, I leave it alone and document the boundary.

How I decide

• Import when the resource already exists, is needed long term, and its current settings are close enough to model in code.
• Recreate when the live object is too drifted, unsafe, or impossible to express cleanly, and downtime or cutover is acceptable.
• Leave alone when it is intentionally outside this stack, or the business risk of taking ownership is higher than the benefit.

Concrete example
Say an existing prod-logs bucket was created manually. If the app depends on it and the bucket policy, versioning, and encryption are acceptable, I would import it, then update the module so the code matches the real settings. If the bucket has years of data and a clean import is possible, import is safest. If the bucket name, policy, or region is wrong and fixing it in place would be risky, I would create a new bucket, migrate traffic or data, then delete the old one after validation.

What I check first
I compare state, config, and live attributes, then run a plan to see whether the desired change is truly just drift or a bigger ownership problem.

I would redesign this so Terraform manages secret references, not secret values, whenever possible. A secret is the actual password or API key. A secret manager is a service like Vault or AWS Secrets Manager that stores the value and gives apps access at runtime.

Workflow

• Store the real secret in a secret manager outside the repo
• Pass only the secret ARN or path into Terraform, not the plaintext value
• Let the application read the secret at runtime using its IAM role or service identity
• Protect state with encryption, tight backend access, and separate prod permissions

Important caveat
If a provider resource truly needs the raw secret during create, Terraform may still record that value in state. Marking a variable sensitive only hides it from CLI output, not from state. So I would avoid designs that require Terraform to own the secret value unless there is no alternative.

Example
Terraform creates prod/db/password as a managed secret container, and the app reads it later. That keeps repo access from becoming secret access.