[bdsa]

You would encode it for the same reason we use source control - confidence that what is deployed matches some kind of record of it.

In development we don't send archives of code to each other (OK, some people do I guess) and in infrastructure we don't click around in AWS to make changes

[kristopolous]

I'm still not convinced on this use case.

The click around technique could have logs and audit trails just the same. Someone could also just type up what they did.

If you're doing 100 of something I'm sold but the record argument I find unconvincing. A preference sure, but a simplifier, no.

[hiatus]

Have you ever worked in a regulated environment? One where you can't just SSH into production and change things? Logs and audit trails provide attribution, not prevention. How do you prevent unwanted changes to production? How do you block changes to production with quality gates? How do you ensure that modules conform to specific specifications before they are launched? How do you do an equivalent to code review? What happens when AWS rolls out a new feature like blocking public access and you have to roll it out to all of your buckets immediately? All of this is much, much more tedious in an interactive system.

[bdsa]

Some great points from a sibling comment, and the one I'd add is:

You don't need 100 instances of something to make managing it programmatically worthwhile. Different environments, for example: Terraform makes it very easy to ensure _all_ of the cloud config in prod matches staging (or the inverse), and to set up and bring down ephemeral development environments, using parameterised Terraform modules so you can be confident changes will propagate appropriately.