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 separate shared logic from environment-specific entrypoints. Right now one large root module is forcing unrelated changes into the same file set, which creates merge conflicts and increases blast radius.

New structure

• modules/network
• modules/app
• modules/database
• envs/dev
• envs/staging
• envs/prod

Each environment folder has its own backend and only calls the modules it needs. Shared values like tags or account IDs can live in small local files or a common variable file.

Why this helps

• Two engineers can edit dev and prod in parallel with less conflict
• A change to app compute does not force a network review unless inputs change
• Cross-environment mistakes are harder because each root has its own state

Example
Dev can use t3.small and prod can use m6i.large, but both call the same modules/app. That gives consistency without a monolith. I would also keep module outputs explicit so one environment cannot accidentally consume another environment’s state.

I would move production to a remote backend that supports both shared access and state locking. State is Terraform’s record of what it created, and locking means only one writer can change that record at a time.

Design choices

• Use one backend per environment, so prod does not share state with dev
• Turn on encryption at rest for the backend storage
• Restrict write access to CI and a small break-glass admin group
• Give most engineers read-only access to plans and state history
• Require an exclusive lock for apply, with a short timeout and clear failure message

Recovery
I would also enable versioning or history so I can recover a prior state file if an apply fails halfway through. If a run breaks, I would not edit state first. I would inspect the lock, compare the current cloud resources with terraform plan -refresh-only, and then decide whether to fix drift, import an orphan, or roll back.

Example
If a colleague applies from their workstation while CI is planning, the lock should stop the second write. That prevents two people from corrupting the same prod state.

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.

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.