Clocks, Processors and Timers on a MCU
The short answer then is "It depends." Different processor families will use different approaches. There isn't a one idea fits all micros answer. Also, synchronous interrupts (those generated by internal hardware sync'd to some internal clock) may be acknowledged more predictably and differently than asynchronous events (external to the micro.) As always, read the datasheet and keep an open mind.

Calculating precise timing will depend upon the processor, as well. Even if an event (timer counter match, external, whatever) occurs, if your processor is busy executing an instruction for several cycles, then it usually won't abort the instruction in order to start an interrupt routine. (But some processors WILL interrupt SOME instructions, even though I just said they usually don't. So even that isn't gospel and you have to read the datasheet and family guides to be sure.) Worse, even if the processor is executing a single cycle instruction, there may be some variability in the interrupt response. So you might find the docs saying "5 to 6 cycles later," for example. So even then, you aren't exactly sure.

On the other hand, some processors are as predictable as an atomic clock. The Analog Devices ADSP-21xx processor (single cycle for EVERY instruction word -- some of which can be performing three instructions in parallel), ALWAYS has exactly the same interrupt response time, every time, to an timer event. You can almost set your atomic clock by it. No variation, at all. Just clean, perfect, predictable responses. Every time.

But that's rare.

And if your processor has a nice, long pipeline, you might have to wait for it to "drain" out. That's done so that there isn't a lot of internal state that needs to be restored, restarting multiple instructions in various stages of execution.

But even then, there are exceptions. The DEC Alpha might take some clocks just to get to your interrupt routine. But when it does, it will probably have several instructions at various states in the various pipelines -- all of which are just sitting there waiting to continue. Your interrupt code will need to save all that state, do its thing, restore that state and then restart ... with all the pipelines back where they were when interrupted. The interrupt code, if it needs to track back and find a faulting instruction, is PAINFUL to write. But that thing screamed. They wouldn't even do lane changes for byte selection because it would add a combinatorial delay which would reduce the clock rate.

So, that's rare. But yes, even that can happen.

SO...... READ THE DATASHEET AND FAMILY MANUAL. And be prepared for ANYTHING at all. Designers can be VERY CREATIVE at times.