Read the plan before you apply.

The plan is the most consequential artefact in operations and the one people skim. It is long, it is repetitive, it is mostly ~ lines that do not matter, and the one line that does is in the middle of four hundred. The industry’s standard practice is to scroll to the bottom and type yes.

 resource "cloud_db_instance" "primary" {
   identifier     = "orders-primary"
   instance_class = "db.r6g.large"
-  username       = "app"
+  username       = "orders_app"
 }

  # cloud_db_instance.primary must be replaced
-/+ resource "cloud_db_instance" "primary" {
      ~ endpoint       = "orders-primary.…" -> (known after apply)
      ~ id             = "db-8f2a1c" -> (known after apply)
        identifier     = "orders-primary"
        instance_class = "db.r6g.large"
      ~ username       = "app" -> "orders_app" # forces replacement
    }
 
Plan: 1 to add, 0 to change, 1 to destroy.

The database is gone. Not because the change was wrong — rotating a credential is a reasonable thing to want — but because username carries ForceNew in the provider schema, and has since the resource was written. A master user cannot be renamed in place, so the only way to honour the line is to build a new instance and throw the old one away.

Every other gym on this site has to build a model to make the invisible visible. This one does not: the tool already computed the destruction, labelled it, and printed it on the screen. A model now writes these changes, and it writes them plausibly. If a person cannot read a plan, no amount of review process helps, because the review is the plan.