7:56 random_string is a resource (and not a function) in Terraform because functions are evaluated every time Terraform plan/apply is run so a random() function would 'taint' whatever resource was using it because each run would evaluate a different random number. See the uuid() function in the docs for a brief mention/warning about this sort of thing. Ideally, you will want your random string to be stateful for the lifecycle of whatever resource consumes it. Because of that, it needs to be a a resource itself.

When deploying with an ADO pipeline I tend to lean on Bicep, the default build containers don't come with terraform. On AWS the argument is more tricky because CF is more annoying even after working with it for a few years now. Terraform started with AWS first and Azure feels like a second class provider in many respects because of it. In terms of scoping, you're right. Since Bicep doesn't cover AAD (another TODO problem of Bicep) I use the az cli to define my LZ's and RG's, scope the IAM and then have complete bicep deploys for the resource groups. It stops the need to modularize every resource and you get that flat hierarchy you're looking for. Finally, getting a client who is hesitant on cloud to pick up both Azure AND Terraform is often too big an ask, sticking with Bicep lets them hire a cloud admin so the position requirements are kept low. Terraform is clean, and even with state surgery issues I enjoy what it does for me, but unless I _need_ multiple providers its always going to be second fiddle to cloud-provided IaC solutions.

Thank you sir for sharing this!! I also like to be like you becoming a Azure Terraformer!! :D

How does bicep handle drift when there are click ops changes?

Great topic, and for sure I think if you go over Terraform state management and terraform cli workspaces for this comparison, terraform would be the winner, please correct me if I'm wrong, Thanks

9:15 i'd prefer terraform, it's too verbose in bicep