Case study two. One thing I see with every large customer is that they have business requirements. They want a document resources. If I'm paying the bill, I want to know who's consuming resources, spinning up VMs for example, and I want to know that this is going through some sort of review process. This customer want me to minimize the impact to the developer productivity. So, as soon as you start to add any sort of process, you slow things down. They were very concerned that I would not hurt their productivity. That was both a technical requirement and a business requirement. So, a customer had this interesting business requirement. Cloud infrastructure resource provisioning must be documented and auditable. Changes to the cloud infrastructure must go through a review process, and a specific requirement must minimize impact to developer velocity. We immediately knew that part of the solution was infrastructure as code. There are a lot of reasons to implement infrastructure as code, but forcing a solution into this implementation means you get the benefits of auditing, code review, and all those things that help satisfy their business requirement. The customer has dozens of development teams, but only one cloud engineer. So, the solution needed to be distributed. Each team is actually responsible for their own process. We map that to technical requirements like this, provisioning infrastructure should be done as infrastructure as code. Specifically, decentralize approval code review process. Teams should own the process. This is how we implemented that technical requirement. We use terraform and Deployment Manager, and IAM strategy based on least privilege, service accounts, and specifically, we utilized source control options such as GitHub Enterprise. They use GitHub Enterprise with a code owners file and the file is a text file that limits who can actually perform actions in the repository.