In .NET, GC is triggered when a user thread runs out of memory in an allocation budget and needs more, similar to what you described [0].
Generally speaking, indefinitely preventing GC from running is not possible (you always end up putting some data on the heap) therefore an optimal strategy is similar to any other language - limiting allocations and reusing memory through object and array pooling. This will ensure that GC pauses are as infrequent and as short as possible. It's important to note that if there is sufficient allocation budget - the GC will not run.
This way, in a well written code the GC may only ever trigger every few hundred frames and only take a millisecond to run. In fact, OSU! has been able to get consistently good frame times even back on .NET Framework.
Dlangs GC for instance guarantee that it will only run on allocation of new memory so it's possible to architect the game to avoid meaningful pauses