The only red flag I could point out is you don't have 100% control of your data. You don't have 100% control of that particular server because it is Microsoft that has access to it. For instance, if you are working with a government organization that doesn't want their data to be resided outside the country, it will not work. You cannot use it because there's no way the data is going to be resided somewhere outside a particular country. Let's say for instance, I'm having an engagement with a Lagos state government with a particular product that need to be deployed and then I can never propose such kind of environment for them because Lagos state will never allow their data to be resided elsewhere except within their data center. In that case, you can't use it. Technology evolves every day and then as technology moves, I move as well. Currently, with what I'm seeing on Azure SQL Managed Instance, it's somewhat perfect, but they still need to do more. But if I'm going to probably figure out what could be the added features within the environment, maybe probably the SA admin should be released to the users within the SQL infrastructure team, SQL team, that is the database team members. Because currently, nobody has access to the SQL admin. The SA admin is one of the greatest accounts. Although Microsoft put a provision for that, your Active Directory account can perform the same function that SA admin can do, because you're not running the SQL within your own VM or physical server. Microsoft controls that. Aside from that, because to me, I don't even see it as a problem because there's a provision for that. In the absence of that SA admin, your Active Directory account can be probably elevated to perform the same function. I don't see anything that's probably against it.
