This question has no constant meaning. Therefore you cannot implement it reasonably without doing something that probably violates every rule in the book. If this is what you think you must do, it is time to rethink. Seriously. Here is why that is so.
The "last" record depends on the sort order. The last record for an ascending sort for field A is different than the last record for a descending sort for field B. "Last record" is PURELY a relative term. You can never use this query field meaningfully in a query. Note also that opening a table and opening a query do not guarantee appearance of the data in the same order, so you can't store this in a table.
Not only that - so here is your recordset in your little query. Now you go delete or insert a record at the end of the table. You might well have changed the designator for "last record." If you hard-coded the size of the table, you just screwed yourself because of the size change. If you stored a real marker in the table, it's probably wrong.
In VBA code, the recordset's EOF property is set to TRUE when you reach the end of the recordset. Forms and reports test this property "behind the scenes" to determine that the current record is, indeed, the end of the set. You can use the EOF property in VBA yourself if you opened the query via a recordset. And if you opened it implicitly through a form or report, you want to use a "footer" section to take some action at the end of the recordset implied by the query.
In any query-based operation, the end of the set is what stops Access from continuing. You could not have told Access to stop earlier without putting a criterion in the query. You cannot tell Access to NOT stop at that place, either. It has nowhere to go if you did. So what value is there to knowing this information? Nothing practical.
OK... now I've told you why you really don't want to do this. So here is how you MIGHT do it if despite my lecture you decide this is the ONLY way you can live another day...
IF the query has a unique key for sorting purposes, add a field that contains an IIF that tests for whether the unique key equals the DMax() of that key using the same filtration rules for the DMax as were used for the query. (I.e. same WHERE clause.) Look up DMax. UNLESS OF COURSE you used descending order, in which case use DMin instead.
If the query has no unique key for sorting, you cannot do this anyway. Because without something unique, you have nothing testable.