Good point about the accidental answers. I'll look at that.
The trouble with hypothetical security questions is that it's so difficult to conceive a scenario where you have a deliberate vulnerability that you want someone to see, yet no other implausible aspects that will throw off anyone capable of seeing it. I am reminded of a murder mystery party I once went to with a group of mathematicians, programmers, and other logical people. When we got to the end of the evening and the true murderer was revealed, I think the majority of the participants had long ago ruled out that suspect on the basis of one of several subtle deductions from the clues provided, none of which had apparently been intended or considered by the authors of the scenario. Instead we were supposed to have ignored all the minor inconsistencies in clues and ambiguities in phrasing, and just gone for the person with the flashing neon sign over their head in the first place...
I'd suggest fine-tuning the question about hashes. My first impression from reading the code, specifically the name user_submitted_hash, was that we were looking at some sort of client-server system where the hash was being calculated remotely and then submitted instead of the original credentials, and that this was a question about not trusting the client. Even without that, in a client-server system the attack you give as the mostly likely wouldn't make much sense given randomness in network latency, so the misunderstanding about the context still breaks the question. Maybe a little more context about how this hypothetical function would be used would help here?
In terms of the presentation here, if you want to show the answers immediately for each question, you might also like to provide some sort of confirmation button. It's frustratingly easy to hit the answer next to the one you intended, particularly on mobile devices. If you're also keeping statistics based on earlier attempts by other people, this is probably distorting your numbers as well.