My experience comes mainly from large banks.

Another factor is which team owns the various layers of the architecture and how they will distribute their output. When making your decision you need to factor in whether you are working with an app per cluster, as is becoming more common in modern K8S systems, or a shared cluster. Simply maintaining a single version for all your applications, infra, and platform will have the same effect. In this answer, I'll mainly address the benefits, techniques, and drawbacks of monorepos, though you don't have to go deep into monorepo culture for this to apply. I think the question you're asking relates to the concept of 'monorepo', where all the code needed to build and deploy your application is contained in a single repo and versioned together.

Application is the business logic and software that runs your business, confusingly this is also often provisioned with kubectl or helm, and possibly packer if you're into the wonderful immutability model.

stuff you typically provision with Packer, kubectl, or helm (and, this is the first blurring, because EKS, AKS, GKE, are often provisioned with terraform too) Platform is Kubernetes, OpenShift, IIS, etc.Infra: machines and VMs, security and resource groups, auto-scaling groups and elastic load-balancers - stuff you typically provision with Terraform.These 3 layers are blurred at the boundaries and there is a continual debate about their delineations, but if you're not familiar with this model, roughly: In this admittedly long answer, I'll talk about the 3 layers of an organisation's IT operations - infrastructure, platform, and application. Tl dr - read the final section, it's the most important. The correct answer, like almost everything in IT, is, 'it depends.' It depends on the way you work, the type of company you are working for, your requirements, your non-functional requirements, and possibly a lot of other factors.

Iac multi ethernet testing