Infrastructure as Code and Automation Questions

A plan that suddenly wants to recreate live resources usually means the state and reality are out of sync, or CI is looking at a different state than the workstation did. State is Terraform’s map of managed objects, so if it is stale or mismatched, Terraform may think a resource disappeared and needs to be rebuilt.

What I would check first

• Same backend, workspace, account, and region in CI and locally
• Whether the colleague applied to the same state file
• Whether resource addresses changed because of count, for_each, or renamed modules
• Whether the provider is now seeing drift in an immutable field

Debug path
I would run a refresh-only plan, inspect the current state, and compare it with the real cloud resources before touching production. If the issue is just an address change, I would prefer a moved block or state mv over deleting anything.

Example
If CI wants to recreate aws_instance.app[0] after a workstation apply, that may mean the list order changed or CI is pointing at old state. I would stop, find the mismatch, then fix state or code first.

I would make the module interface small, typed, and caller-driven. A module should accept inputs through variables and return only the outputs another team needs.

Inputs

• env for environment name like dev, staging, prod
• name_prefix for naming consistency
• tags as a map(string) so teams can add ownership and cost-center labels
• sizing inputs, such as instance_class or cpu_count
• network inputs like subnet_ids and vpc_id

Design rules

• Use defaults only for safe values, not for important architecture choices
• Add validation so bad values fail early, such as rejecting an empty subnet list
• Use stable names and tags inside the module, but let callers control the prefix
• Output IDs, ARNs, DNS names, or endpoints, not whole resources

Example
Dev can pass instance_class = "t3.small" and prod can pass instance_class = "m6i.large", while the module code stays unchanged. That lets each environment differ in size and naming without forking the module.

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.

Approach
I treat a shared Terraform module like an API. First I classify the change: additive and backward-compatible, or breaking. If it is additive, I release a new minor version, keep existing variables and outputs unchanged, and make the new capability opt-in with a default that preserves current behavior. If I must rename or remove something, I publish a new major version and keep the old one available for a transition period.

How I keep upgrades predictable

• Use semantic versioning: patch for fixes, minor for new optional features, major for breaking changes.
• Pin module versions in callers, for example ~> 1.4, so teams only receive compatible updates.
• Add tests that run old examples and new examples in CI.
• Publish a changelog with migration notes and deprecation dates.
• Announce the change early, then give teams a canary path in one workspace before broad rollout.

Concrete example
If the module currently creates an S3 bucket and I want to add optional access logging, I would add enable_access_logging = false and a new logging block. Existing consumers get the same bucket as before, while teams that want logging can opt in. After a release or two, I can deprecate any old workaround variables without breaking them immediately.

Result
That approach lets teams upgrade on their schedule, keeps state changes predictable, and makes ownership clear.