> Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state It doesn’t matter how the state is stored, you stil

> Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state It doesn’t matter how the state is stored, you still need to reconcile it. So yeah you can write your target state into a database if you wish, but you need something else to compare that with the state of the actual world and progress that towards the state you requested. > When you have an actual database backing your SQL queries, the migrations would all run in this DB, produce a final state of the DB, then this final state would get applied to bring up your system in one shot. Yes, what you are describing is how Terraform works. Without SQL. Except it’s never “one shot” because it’s a DAG of requirements where each resource creation can fail. > Sure, and that's fairly easy to derive, because we already have a unique identifier, the bucket name In this specific case, sure. But for a KMS key or in the general case, no you wouldn’t. You’d also be hard-coding provider specific information into your system - “a bucket ARN can be derived from the name attribute”. This is not always the case - consider any REST api that accepts a POST request to create something, but returns only an incrementing integer primary key to uniquely identify it.