diff --git a/docs/database-engine/availability-groups/windows/contained-availability-groups-overview.md b/docs/database-engine/availability-groups/windows/contained-availability-groups-overview.md
index c47a1156ee2..c194b416cad 100644
--- a/docs/database-engine/availability-groups/windows/contained-availability-groups-overview.md
+++ b/docs/database-engine/availability-groups/windows/contained-availability-groups-overview.md
@@ -49,7 +49,9 @@ Each contained AG has its own `master` and `msdb` system databases, named after
 > [!IMPORTANT]  
 > Contained AGs are a mechanism for keeping execution environment configurations consistent across the replicas of an availability group. They **don't** represent a security boundary. There's no boundary which keeps a connection to a contained AG from accessing databases outside of the AG, for example.
 
-The system databases in a newly created contained AG aren't copies from the instance where the `CREATE AVAILABILITY GROUP` command is run. They are initially empty templates without any data. Immediately after creation, the admin accounts on the instance creating the contained AG are copied into the contained AG `master`. That way, the administrator can log into the contained AG and set up the rest of the configuration. If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. You need to manually re-create them in the contained system databases within the context of the contained AG. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database.
+The system databases in a newly created contained AG aren't copies from the instance where the `CREATE AVAILABILITY GROUP` command is run. They are initially empty templates without any data. Immediately after creation, the admin accounts on the instance creating the contained AG are copied into the contained AG `master`. That way, the administrator can log into the contained AG and set up the rest of the configuration. 
+
+If you create local users or configurations in your instance, they don't automatically appear when you create your contained system databases, and they aren't visible when you connect to the contained AG. Once the user database has been joined to a contained AG, it will immediately become inaccessible to these users. You need to manually re-create them in the contained system databases within the context of the contained AG, by connecting directly to the database or by using the listener endpoint. The exception to this is that all of the logins in the sysadmin role in the parent instance are copied into the new AG specific `master` database.
 
 #### Restore a contained system database