That is correct.
For many of our published ArcGIS Server services - we use the "Operating System Authentication" (OSA) login when publishing. This is the Active Directory (AD) account that the ArcGIS Server runs as. Our data admins/publishers will grant the ArcGIS Server AD account the read/write permissions to the database objects. Most of these workflows are for read-only access - publish the service and let customers consume it for mashing up with other datasets.
Although for some workflows (like the Esri offline 'feature server sync' capabilities) we use a SQL Server built-in account; we do NOT use the OSA account. The main driver for this was when the user syncs an offline map, there is a version created and owned by the account that was used to publish to server with (so the account the server uses to connect to SQL). If we used the OSA account, then it was challenging to manage that version without having full geodatabase administration ("sde" account) access. With the 'headless built-in SQL account', we can provide that account connection file to certain staff members who can then manage their back-end version by rec/posting to the parent version. The only way to do that with OSA would be to login to a computer with that same OSA account, or over-ride the version permissions to "PUBLIC", or give the user full SDE level admin access.
So for the situation highlighted above...
GIS Specialists use a built-in SQL account to 'own' the data. This is the account they would connect as when creating a feature class, granting permissions, applying indexes, making schema changes, etc. Lets call this account "dataowner". Objects in the database (lets call the database "mydatabase") end up looking like: mydatabase.dataowner.table_name
The GIS specialists then use a different built-in SQL account to 'publish' the data to ArcGIS Server. This is the account they would connect with when publishing from ArcMap/ArcGIS PRO. Lets call this account "dataeditor". The GIS Spec will use the "dataowner" account to grant read/modify permissions on the "table_name" to the dataeditor account.
When the user synchronizes the offline edit, then a version is usually created in the geodatabase that is owned by the 'dataeditor' account. EX - dataeditor.my_version
The problem we ran into was that when the 'dataeditor' SQL account was created, it was inadvertently mapped to the schema owned by "dataowner".
HTH.