IMHO mono-repo vs multi-repo should be decided based on the sources of change for each component in a product. For example, the cloud components of a product usually change at the same pace and for the same reasons, it makes sense to have them in a mono-repo. Even in a microservices approach. Even in the cloud certain components can change at a different pace and for different reasons. For example if you have grpc api that talks to your mobile app and a webapi exposed to your customers.
I believe that components that move at a different pace and change for different reason should not be in the same repo. It is difficult to setup CI/CD for different ways of deployment and specially if they not changing at the same time.
Now, regarding security, it is important to keep different components of a product in different repos, this will give you the flexibility to manage a more restricted set of credentials and reduce the number of people that have access to it.
In the end it involved 3 things: 1) Sources of Change, 2) CI/CD Processes and 3) Security. You can definitely mix and match.
I believe that components that move at a different pace and change for different reason should not be in the same repo. It is difficult to setup CI/CD for different ways of deployment and specially if they not changing at the same time.
Now, regarding security, it is important to keep different components of a product in different repos, this will give you the flexibility to manage a more restricted set of credentials and reduce the number of people that have access to it.
In the end it involved 3 things: 1) Sources of Change, 2) CI/CD Processes and 3) Security. You can definitely mix and match.