Infrastructure as Code and Automation Questions

I would review it from top to bottom with a bias toward clarity and safety.

Provider config

• Pin the provider version so behavior is reproducible
• Confirm the region and account are explicit, not inherited by accident
• Check whether aliases are used correctly for multi-account access

Resources

• Look for hard-coded IDs, names, or CIDRs that should be variables
• Check that dangerous resources have sane lifecycle settings
• Make sure dependencies are clear and not hidden in implicit assumptions

Variables

• Give each variable a type and description
• Add validation for things like CIDR shape, allowed instance sizes, or non-empty lists
• Mark secrets as sensitive, but remember that only hides output, not state

Outputs

• Expose only what other modules need, such as IDs, endpoints, or ARNs
• Do not output passwords or full secret payloads

Example
If I see a hard-coded 10.0.0.0/16 and a shared-account provider with no explicit role assumption, I would flag both. That makes the config less portable and hides an assumption that could break a later environment.

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

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.