I have a client that resides in the Azure data platform arena, focusing mainly on Platform as a Service (PaaS) and Azure SQL DB. They have a decent landscape of Azure resources and currently utilize failover groups within SQL DB to facilitate high availability. Under the covers, failover groups are essentially Availability Groups and have similar issues that you might encounter with the on-premises version.
A common issue that you might encounter, which my client did recently, revolves around orphaned users. Orphaned users occur when the user object in the database has a different SID (security identifier) than what the login says it should be. It is also possible that the login may not exist at the server level. Orphaned users are also specifically related SQL Logins and not Active Directory authentication. When dealing with on-premises databases, this was commonly found when restoring a database from one server to another and you had to manually adjust the database user to fix the incorrect SID. Regarding Azure SQL DB and failover groups, orphaned users can also occur. The login is first created on the primary server and then the database user is created in the user database. The syntax would look like this: