This question is somewhat confused and the answer is wrong.

It says the files "not be removed immediately" and asks how to force this garbage collection to occur. The word "this" means something, and the only thing "this garbage collection" can be using as a referent for "this" is removing the files. As the garbage collector will do nothing with the files unless both the current checkpoint LSN and the last backup LSN are both beyond the LSN of the delete operation, and the files will only be removed when the garbage collector has processed them twice, causing the garbage collector to run will do nothing at all unless there has been both a checkpoint and a log backup since the delete operation, and even if this forced run occurs when the backup and checkpoint LSNs are both high enough it will not remove the files if it is the first such run, just mark their tombstones so that the next GC run will remove them.

So the correct answer is that there is nothing you can do (short of issuing a checkpoint , starting a log backup and waiting for it to complete, and then calling the SP twice to force two GC runs) to cause "this garbage collection" (which in context, because of the use of "this", can only mean removal of the files) to occur.

This is fairly clear from the BoL page referenced in the explanation. The result set returned by the SP tells you how many files were marked for collection and how many were not processed at all. Why should either of these numbers be non-zero? Because when the garbage collector runs, it may not remove the files (it won't if it has not marked for collection during a previous run), and it may not even mark them for collection (it won't if the checkpoint and backup LSNs are not both later than the LSN of the delete operation).