1. Use a unique key check that will fail if there's already a VM with the given key. 2. The OP mentioned that you can snapshot the database and restore it to a

1. Use a unique key check that will fail if there's already a VM with the given key. 2. The OP mentioned that you can snapshot the database and restore it to a known-good state if anything goes wrong. State databases are probably not going to be humongous in size–you can imagine snapshotting them hourly for quite a long time. 3. How do you solve this problem today? By running Terraform applies locally on your machine to test out the modifications and then approving the PR? 4. That's exactly where foreign keys come in, they are exactly what enforces correct handling of dependencies between resources. E.g. some time ago one of our PagerDuty service monitors was renamed in Terraform. The plan destroyed the old monitor and created a new one with the new name, losing the linkage to the old incidents and making it look like the service had no incidents. Now imagine modelling this relationship in IaSQL and failing to destroy the old monitor because of the incidents.