I think the first thing to do is make sure you know exactly what you need. Chances are you want to start with SQL as AceCTO suggested. My reasoning for starting there is different however.
The basic point is that standard SQL is a pretty mature technology. You know what you get. It is robust also, so you don't have to deal with the questions that things like VoltDB (a "NewSQL" solution) bring up regarding durability of your data. VoltDB is ACID-compliant for some values of C and for some values of D, but those values are non-standard. If you need to move to it you always can, possibly as a helper for a standard RDBMS. NoSQL is fragmented, but the tradeoff is more basic.
With NoSQL you are typically moving from a relational database which specializes in flexible, well-contracted data output to a non-relational database that specializes in flexible, vaguely-contracted data input. This tradeoff is massive. It means, on the positive side, that you can just throw data at the database and not worry about whether it is valid or not. On the negative side, not only does it mean you can throw data at the database without worrying about validity, but it also means that that you are giving up on set-based manipulation of the data using well-structured mathematics. These are massive downsides and almost never worth replacing an RDBMS with a NoSQL solution.
As for scalability, on good hardware, PostgreSQL can scale up to a hundred thousand transactions per second on TPC-C tests. Additionally even if you dont want high-end hardware, you could scale outward with Postgres-XC if you need to on smaller servers. Additionally your check for whether a player has seen a question is likely to be set based and far easier to do in a way that performs well than you would with a NoSQL solution.
Long-story short, start with SQL. You can always add helpers, whether NewSQL or NoSQL as you need to, but chances are relational math is too valuable to throw away.
