Both 7 and 10000 will fit in an int data type, do the math is done in ints. But 70000 will not fIt in an int so it overflows*. Try 7 * 10000UL; to force the math to be done in unsigned long.

How large will your number ever need to be?
Will it ever need to be negative?
You can use a uint32_t for large positive only integer types, and int32_t for large positive or negative types.
0 - 2^32 - 1 for uint32_t
-2^16 - 2^16-1 of int_32_t

The compiler does things in steps. A 10000 is seen as a integer, regardless if you put that in a certain variable. A 7 is a integer. So the compiler sees two integers and does therefor a integer multiplication. Then the compiler can put the result into a unsigned long.

A 1000000000 does not fit into a normal 16-bit int, but luckily it still fits in a unsigned long. The compiler tries to help you and does not use integers anymore. But the default for a compiler is always int on every Arduino board, on every platform.

Sometimes when using 8-bit bytes, the compiler chooses int for a calculation. There are very clear rules for that, but even I don't know all those language and compiler rules.

You can avoid all problems by always using 'UL' for numbers and always use unsigned long variables.
Then you are sure that the compiler understands what you want, and it is helpful for yourself as well, because it clearly shows that the code is with unsigned long:

// unsigned long ? then unsigned long everywhere.
unsigned long a = 1UL;
unsigned long b = a + 2UL;
unsigned long d = 7UL * 10000UL;
Serial.println( 7UL * 10000UL);
// float ? then float everywhere:
float p = 1.0;
float q = p * 3.456789;
float r = (float) analogRead(A0); // cast to float

The Arduino reference shows the limits for 32-bit unsigned long:

In binary arithmetic this is 0001 0001 0001 0111 0000 (hex 0x11170).

Most likely, as mentioned above, the result is truncated to 16 bits. This means that only the first 16 bits (counting from the right) will fit in the result. Truncation occurs before the result is stored in a variable, and by then it does not matter if this variable is 32 bits wide, because the result has been truncated.

The result here would then be truncated to 16 bits and is 0001 0001 0111 0000, which is 4464 in decimal (hex 0x1170).

To force the arithmetic to be performed using long integers (before it is ever stored in a variable), at least one of the operands must be a long integer. You can achieve this forcing 70000 as in 70000L, or using a long variable in the multiplication.

The data type of the number to the left of the = does not matter. The numbers to the right of the = will still both fit in an int data type so the math is done with ints. The result is too big to fit into an int so it is truncated and put into the variable on the left even though the variable on the left is an unsigned long data type.