Then again, I’m sick and maybe I’m misreading it, if that’s the case, my apologies.

Don’t hate me here but this feels like that meme where the guy puts a stick in the spokes of his bike and blames the stick.

I think that’s just a process problem, definitely depends on the specifics of your organization but I think if you raised that concern, you could probably come up with a solution that isn’t quite so burdensome, while maintaining the maturity level of IaC.

And I hate to be that guy but that last sentence doesn’t seem have much at all to do with IaC. Big shops can use IaC, so can small shops. In my case it’s the latter, we just have so much tech spread across so many platforms that maintaining it purely via GUI is infeasible. IaC is simply the best way to go for us, due to the sheer number of moving pieces.

To me the power of IaC is less in “I can stand this whole thing back up a single deploy” and more "The entire history of every configuration decision and change I’ve ever made is right here, not buried 4 submenus deep in a “new enhanced ui”.

When we’re being audited for security/privacy/legal compliance, I have one source of truth to look at, and when it gets changed, those changes get peer reviewed just like any other code change, and git history is a great audit trail if you use decent commit messages.

Also, knowledge transfer and onbording is way easier too, here’s all our infrastructure, here’s the rules surrounding how it gets updated, yes you will be fired if you break them. Here’s the docs regarding how to write this code, and here’s some handy formatting and validation scripts to help you along the way.

Doing it by hand in the console is fine if you have full confidence in your ability to hand over the project to another human on your way out the door, but when it comes to that one hacky workaround you had to implement with no documentation due to the limitations of your in-house apps, you’re probably forcing the next guy to rediscover why you did it that way by breaking it half a dozen times on the next deploy after your departure, rather than just noticing the inconsistency in the IaC, then looking into the git blame and mumbling “heh, that’s dumb”.