Infrastructure as Code and Automation Questions

I would consume the shared network with data sources or, if the network team publishes outputs, with terraform_remote_state. A data source is Terraform’s read-only lookup for existing infrastructure. I would prefer explicit outputs for IDs, because they are less ambiguous than searching by tags.

What I would check

• The VPC ID matches the expected CIDR, for example 10.20.0.0/16
• The subnet count is what I need, for example 2 private subnets in us-east-1a and us-east-1b
• Subnet tags match my assumptions, such as tier=private and env=prod
• All subnets belong to the same VPC

Fail loudly
I would add variable validation plus precondition checks so the plan stops before apply if the layout is wrong. For example, if I expect exactly 2 private subnets and only find 1, the module should error instead of guessing.

That approach keeps the module reusable, but still safe when the shared network changes.

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 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.

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.

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.