You can do that by setting up an ODBC connection to the spreadsheet, but as Brian mentioned, the file would need to be somewhere accessible.
The catch with ODBC Excel connections is that they require exclusive access to the file; i.e., if another user has it opened you will get an error, so if your file is in a place that makes it accessible to other users there is a greater chance of a connection failure.
For example, if your Workflow attempts to read data from the file while another user has it open, or if someone moves/renames the file, the activity will fail and the workflow could be terminated unless you have a Try-Catch in place.
What I've done to get around those kinds of issues is store a copy on the server and use that to configure the OBDC connection for Workflow.
Before the query activity I have a Script activity that attempts to overwrite the local copy with the copy from the shared drive. If it succeeds, you have the latest version. If it fails, you can either throw an error or just use the last copy you made on the server.
Your Workflow service account would need access to the shared location for the copy script to work, but the big advantage to this approach is that you don't have to worry about exclusive access.
Since you want the data sent back, you could add another script after the data update that overwrites the shared folder copy with the server copy.
The most important thing is that you want to make sure your workflow can always access the file, and that could be problematic if it is readily available to other users.