Review a proposed database infrastructure change.

Instruction: Before revealing Stage 2, name the evidence needed to explain the plan. Then propose a correction and the exact outcome to verify.

Context:

Stage 1. A fictional production Terraform plan proposes the actions below. The change request says "organize orders infrastructure." Do not assume a refactor or a legitimate replacement from that description. State two plausible explanations and the checks required before any apply.

# Sanitized action summary; not a complete Terraform plan
aws_db_instance.primary: destroy
aws_db_instance.orders:  create
Plan: 1 to add, 0 to change, 1 to destroy.
Stage 2 — inspect after naming the evidence you need

The controlled comparison confirms the same workspace, backend, provider alias, provider version and remote object. Terraform is version 1.1 or newer. All database arguments are unchanged; the only configuration diff is the resource label. No move declaration exists.

- resource "aws_db_instance" "primary" {
+ resource "aws_db_instance" "orders" {
Verified factValue
Existing state addressaws_db_instance.primary
Recorded provider object IDorders-prod
Intended database identifier at new addressorders-prod
Engine, storage and other database argumentsUnchanged in the full reviewed diff

The excerpt is not a complete resource configuration. The database contains production orders.

Updated

Example Answer

I would stop the apply and compare configuration, state/object identity and provider context. Separate destroy/create actions could reflect an address-only refactor, or a real infrastructure change; the short change description cannot decide that.

Stage 2 supports an address move for the same database. I would add a reviewed moved block from primary to orders, then create a new plan in the verified context. The acceptance condition is retained object identity with no unintended database replacement, followed by review of every other action. Backups do not justify an unexplained destroy.

Worked reasoning

Before the reveal, compare the full configuration diff and state binding. Check whether orders is intended to refer to the existing object, whether a database argument genuinely requires replacement, and whether the plan used a different backend or provider context. Do not make names match by manually editing state.

The Stage 2 correction uses Terraform's explicit refactor mechanism:

moved {
  from = aws_db_instance.primary
  to   = aws_db_instance.orders
}

Re-plan with the reviewed configuration and correct state. Inspect the recorded move, remote object identity orders-prod, and all remaining actions. A correct address association should remove the address-only destroy/create pair; it does not overrule real provider replacement requirements. Retain the move declaration for upgrade paths that still begin at the old address.

Falsification: if the new plan still replaces the object, inspect the replacement-causing attributes, state binding and provider behavior. The address issue may be resolved while another cause remains. Stop until the remaining change is explained; an actual replacement requires its own data migration, cutover and recovery plan.

A local fixture with a built-in resource can demonstrate move semantics and retained identity. It does not establish how the AWS provider handles every database argument or what a production apply will do.

What the interviewer is assessing

Core checks (1 point each):

  • Withholds the destructive apply and asks for configuration plus state/provider-context evidence.
  • Uses the revealed same-object facts to write the correct primary-to-orders moved block.
  • Re-plans and checks retained identity, absence of unintended replacement and remaining actions.

Stronger (+1 after all core checks): Separates a Terraform address refactor from a provider-required replacement and explains the evidence needed for each.

Acceptable alternatives: A controlled state move can work under compatible tooling/backend constraints, with equivalent identity evidence and re-plan review.

Red flags: Approves destruction from the ticket title, removes protection to make apply pass, or claims a moved block makes any configuration change nondestructive.

Follow-up

The moved block is present, but a storage-related change still requires replacement. What next?

Example response: Confirm the exact provider rule and whether the setting change is intended. Revert an unintended setting or design an explicit migration with data verification, cutover and recovery. Do not remove the move or alter state merely to suppress the remaining replacement.

Related Questions