It's 2×3×4×5×6×7×8×9. I knew that such a modulus wouldn't change the outcome of the exponentiation operation, but would greatly reduce the size of the result. I didn't put nearly as much thought into it as brandenge's comment implies. I guess I got lucky that it worked.

upper bound and overflow are quite understandable thing.
but could that number be lower and could some test broke cause it isn't low enough now - I cannot easily understand.
btw it seems to me that in should be divisible by 20, not just 4.

anyway I was surprised as haven't used second parameter of .pow and wasn't aware of it existence before

I was wondering the same thing. My current mental model is that it can be any arbitrarily large modulo so long as it is: A) a multiple of 4, B) correct, and C) won't cause an integer overflow, with the range of integers being tested. I believe they chose that particular modulo somewhat arbitrarily, just approximately based on the size of the largest numbers that were being tested for. If larger numbers were being tested, it would still cause an integer overflow error and thus would not work. Basically there is a lowerbound on the size of modulo you can use without the conditional check (that uses the additional logic of expoonent % mod + mod when exponent > mod), otherwise it will lead to incorrect results. And there is an upperbound on the size of modulo you can use, which is whenever it causes an integer overflow. Both bounds change depending on what range of integers are being tested. This solution opted to flirt with the upperbound to make it more concise without the conditional, which works for the current range of integers being tested. But the tradeoff is still there in that a different, larger range of integers being used/tested would cause it to fail still.

Nope. They are just "informative"/for fun. You don't need them in any way to solve the task.

Why is this an issue?

Any chance alt text could be added to these images for low-vision users?