Answer: False.
Why? because number of instructions is IC, and the number of clock cycles per instruction is CPI, and BOTH depend on the ISA of the machine on which they are being executed. Since they share a common source, and modifying the ISA could cause changes in both, it's hard to consider them as independent. Now, if you say that you are assuming a given architecture or ISA in your ``reason'', I'd think that partial credit would be available. However, in general, they aren't statistically independent.
Answer: False. Be careful here. Decreasing the clock rate means that there are FEWER ticks per second, or more clocks per tick, which is equivalent to making the clock slower. Remember, units of rate are cycles per second, and time are seconds per cycle.
Also remember that performance is the inverse of clock cycle time because performance is a rate.
Answer: Who Knows?
This one is a bit nasty. If your Java virtual machine is purely software AND you have a small RAM, it may be that you can't improve the performance by making the clock faster because your process is memory-poor and will be stuck page faulting. That is, you don't have enough memory to be able to take advantage of the quicker clock.
If you are using, say, a Java chip--and there are some, or you have enough memory, it is indeed likely, if all other parameters remain unchanged, you will see improvement in the execution time.
Answer: False. This is NOT sneaky. It's the same idea as in the first problem in this section. When you modify the ISA, both the IC and the CPI may change because the program still has to do the same job, but using a slightly different implementation for some of the instructions, and even eliminating or adding instructions so as to change the average CPI. Thus, it is naive to expect no change in the IC when the CPI changes.