It's in the resource allocation/generation process of your deployment things get tricky.
The first thing you're going to have to do is the networking. You're not going to deploy things on the internet in an Enterprise Organisation, so you're going to have something that can make sure your application gets on the right VNET and the right subnet. Obtains the correct private-endpoints. Gets a DNS address so people can go to https://yourapp.yourcompany.com from the internal on-prem network that will need a DNS routing as well because it's not going to ask the internet. Once in a while, when you actually want your app to be accessed from the internet, you're going to need some sort of gateway resource that can transfer the traffic through whatever security your org has setup in such a way that it blocks, every, IP you're not intending on letting through.
The second thing you're going to want is a place to persist your data. You can have a centralized shared database, and most places use this, but the issue with that is that it'll eventually end up a mess. Not by bad intention, but because it's just very easy to build stored procedures, views and whatever else on top of the data from all those 100+ applications that are sharing the same DB server because it's a quick way to deliver business value (until it isn't). It also doesn't scale, which will eventually be an issue for you even if you aren't netflix. The flip-side is that you can't actually do a bunch of managed DBs because that is ridicilously expensive, and you likely can't use the CosmosDB (and whatever the AWS equvilient is called) because of company red-tape and also because your 3rd party DB backup vendor doesn't support it. So you either run them in containers, or share servers, or run up the bill. Two of those solutions require all the steps in the networking step, because they too need to be on the right private endpoints on the right subnets on the right VNETs, and all of them will need you to grant some sort of access rights through your IDM. Which is often as simple as giving your apps some sort of managed ID and then adding it to some AD group, but that's still something that needs to be done.
Deployment slots: now we're moving into the more ridicilous parts of it, but you're probably going to need to deploy your application at least twice. It'll probably be three or more, but it'll be at least twice. Each of these slots require that you go through the two previous steps. If you're wondering why, then it can be as silly as because some Enterprise Architect lied in a meeting and convinced everyone it was required by law, similar to how you're also forced to put 4-6 eyes on every pull request (though to be fair, this part makes sense).
And that's if you're using serverless dockerized function apps in Azure in an enterprise organisation. If you're not doing serverless it gets way worse. Sure kubernetes, travis, openshift and so on can do it much smarter, but in non-tech enterprise you don't have anyone employed to manage it.
@jiggawatts really put it well when he said this in one of the other comments:
> there are great solutions for the solo dev doing click-ops for one app, there are great solutions for megacorops doing automation at scale for thousands of devs, but in the middle where you have a couple of enterprise devs managing a few dozen apps its just madness.
In all seriousness I've written and deployed business critical serverless applications, which are less code than the bicep and yaml required to deploy them, and here is the biggest issue, I have no idea if my bicep is actually good because GPT wrote most of it.