Let's look at what ACTUALLY happens when you execute the line of code you gave us. I'm being pedantic so that my answer will be clear when I'm done. That line is executed in VBA context, which has sufficient vision to see forms, controls, modules, and variables provided they are PUBLIC with respect to the place where that code is executed. SO...
The CurrentDB.Execute is parsed. The call template for that method of CurrentDB allows two arguments, the first of which must be either the name of an SQL object (a named query, e.g.) or a string containing the SQL itself.
The parser next sees a quote mark, which means "Literal string follows." So it starts accumulating the string until the quote near the right end of that first line. The line still isn't exhausted. VBA sees the ampersand which implies another string is coming. Then the underscore, which says that something is coming on the next line. Then you hit the end of the line but with expectation of a continuation line.
The next line starts with another quote ("another string is coming.") You supply that string, but then you have that sequence in which you break the string, insert ampersand, a function, another ampersand, and another string. You have that function outside the strings. It gets evaluated to return its string (value). Concatenation occurs, double-ended because ampersands before and after the thing that WASN'T a string. At that point the string reads "whatever was the first part" plus "whatever was returned by the function" plus "whatever was the second part of the quoted string." At the end of that sequence, you have a complete string, which will fulfill the 1st argument required for the .Execute method. The 2nd argument is optional so you are good.
At this point, Access from its VBA context now passes the string to the SQL processor, probably ACE but just as well could have been something else. Let's just say ACE for sake of discussion. The most important fact to remember here is that VBA and Access are in their own chunk of memory, but the SQL engine is another process or sub-process with different memory. Physically different, non-shared memory. Windows rules on process separation mean that Access and ACE are different processes that CANNOT SEE EACH OTHER (except through the control interfaces.)
Now the SQL parser kicks in on the string that was passed to ACE. It sees the UPDATE, a table name, a SET clause with two parts (one of which is a function), and a WHERE clause with two parts that are at this time literal values - because the substitution occurred while in VBA context.
ACE cannot yet operate on this because it has to decide if it can see the GetComputerName() function that was passed in to it within a quoted string. And here is where I can now specifically and directly answer your question.
Anything visible to VBA can be used including your module property if you are going to substitute it because VBA can see anything that is public. BUT if you enclose the property in quotes, VBA cannot perform substitution and therefore SQL has to look for that item. But that item might be in physically different memory and thus not visible to the SQL parser.
So... YES, you can use your property of a module IF that module property is visible to VBA AND you substitute it into the string. This is why we often suggest that you build the SQL string for a .Execute separately from the actual .Execute line. That way you can debug or DEBUG.PRINT that string to see what you actually tried to do.