Usually, all data is written via the Access Database Engine, unless you're doing something weird.
In most situations, it works like this:
- Tool submits a query via OLEDB/ODBC/DAO to the Access Database Engine (DAO360.DLL/ACEDAO.DLL)
- Access Database Engine determines which data should be read/written to where (to the file/remote data source)
- Access Database Engine uses the connect property of the linked table to try and open a connection if necessary, and creates a new query or multiple queries in the appropriate SQL dialect
- Access Database Engine submits query/queries via the opened connection
However, this can go wrong:
- The tool doesn't actually use the Access Database Engine at all, but tries to directly write the file (via UCanAccess/MDBTools/proprietary driver), and those don't support linked connections at all
- The connection string in the linked table requires an ODBC driver, password, resource, or something else that's not present or not in the right place
- The linked table requires some sort of implicit authentication (e.g. SharePoint), and this doesn't happen
- The data source used by the linked table requires a specific lock type (e.g. dbSeeChanges for opening a Dynaset-type recordset on SQL server) which is not used by the tool
And of course, many, many more things can go wrong (in fact, I crashed Excel in an attempt to test reading a linked SharePoint lists while writing this answer).